►
From YouTube: IETF99-DHC-20170719-1330
Description
DHC meeting session at IETF99
2017/07/19 1330
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
D
B
B
B
E
C
B
Do
not
have
a
working
group
secretary,
but
if
anybody
is
interested,
let
us
know.
Okay.
The
agenda
is
as
follows:
we'll
take
a
few
minutes
to
do
some
administration
at
minister
via
agenda
bashing
things
like
that,
then
we'll
have
john
grochowski
present
on
some
DC
PV
deployment
stuff
a
Comcast.
We
have
a
discussion
on
secure
dhcpv6,
as
there
were
some
issues
raised
recently
on
that
document
and
some
concerns,
and
so
the
question
is:
what
do
we
do
about
it?
Do
we
need
to
make
some
significant
changes?
B
Just
a
quick
update
on
the
working
group
document
status,
there
were
two
RCS
published
the
failover
protocol
for
v6
and
the
prefix
length
hint
issues.
One
RC
is
in
the
editor
queue
and
we
have
six
working
group
drafts
that
are
currently
active.
Details
can
be
found
for
those
on
the
data
tracker,
so
quick
update
on
33
15
biz.
B
We
did
have
a
working
group
last
call
last
summer
which
generated
about
270
issues.
We
did
publish
a
new
version
in
March
of
2017,
which
addressed
most,
but
not
all,
of
the
issues,
and
then
we
published
one
in
May
which
address
the
remaining
issues
and-
and
we
initiated
another
working
group
last
call
on
that
document
and
received
reviews
with
about
30,
mostly
minor
issues,
there's
a
few
that
were
a
little
bit
more
significant,
but
most
of
them
were
fairly
minor
edits
to
the
document.
B
There
will
likely
be
a
10
before
we
do
send
it
on
one
made
dependent
will
depend
on
what
happens
with
a
secure,
DHCP
v6
work,
because
currently
the
3315
biz
does
reference
that,
and
if
we
determine
we're
not
going
to
make
much
progress
on
that
document,
maybe
it's
not
appropriate
to
reference
it.
Another
is
that
I
had
meant
to
update
Appendix
A
to
include
some
clarification
regarding
the
lifetimes.
That
was
an
issue
raised
by
Jin
May
that
we
addressed
in
the
onine
document,
but
I
forgot
to
mention
it
in
the
updates.
B
The
changes
that
we
did
and
hopefully
we'll
get
a
few
reviewers
to
review
the
changes
we
made
for
the
O
nine
and
confirm
that
they're,
okay
or
provide
us
a
few
additional
edits
that
we
will
make.
So
please
do
review
the
O
9
and
again.
The
goal
is
to
publish
the
10
in
early
August
and
send
that
on
to
Suresh
our
ad
and
the
iesg,
eventually
and
we'd
like
to
thank
Ralf
for
being
the
document
shepherd
and
doing
the
working
group
consensus,
determination,
work,
any
questions
about
any
event
and
I
didn't
really
stop
to
ask.
G
B
G
G
Dsp
has
been
a
critical
part
of
stockist
networks
since
the
beginning
of
its
time
that
that
didn't
change
with
before
and
I
think
you
know,
as
you
know,
we
don't
have.
We
may
not
have
some
love
for
DTP
DCP
in
the
room
right,
but
I
think
the
the
byproduct
of
its
availability
is
unquestionable
right.
It's.
It's
basically
enabled
companies
like
Comcast
to
take
ipv6
connectivity
to
tens
of
millions
of
customers
right.
So
that's
yeah,
that's
material,
so
we
did
that
work
in
2005
spend
a
lot
of
time
over
past
10
12
years.
G
Writing
things
like
these
P
servers,
C,
MTS's,
network,
etc,
and
next
slide
and
we'll
talk
a
little
bit
about
where
that
stands
today.
So
today,
in
our
network,
99%
of
about
44
million,
cable,
modems
used
HP
v6
and
they
are
v6
only
90
percent
in
growing
of
our
ear
adders,
our
dual
stack
provisions,
so
they
both
get
an
I
na
and
an
IP
D
and
99%
of,
and
that's
probably
about
20
million
21
million
and
for
set-top
boxes,
which
is
a
video.
G
G
Implement
v6
client
that
we
used
for
our
set-top
boxes
or
set-top
boxes.
If
I
can
go
back,
you
know
need
to
move
the
slides
but
I'll
point
back
to
that.
They
both
get
in
I
na
and
I
PD,
so
I
set
that
walk
is
more
like
a
video
gateway
right.
So
it's
a
host
and
a
router.
So
we
treated
a
lot
like
a
near
our
right
and
our
set
that
box
happens
to
use
the
dibbler
implementation.
G
Probably
you
know
slightly,
you
know,
aged
version,
which
you
know
I'm
sure
I'll
get
some
criticisms
for
here
momentarily,
but
we
happen
to
know
somebody
in
the
room
that
has
knows
something
about
diddler
I.
Think
next
slide,
please
yeah
yeah
yeah,
so
some
observations
it
has
been
extremely
stable.
Probably
you
know
honestly
that
this
wasn't
an
arbitrary
decision.
We
took
a
look
at
a
lot
of
the
other
implementations
and
landed
on
this
one
because
of
its
stability
and
ease
of
use.
I
came
with
a
lot
of
things
that
worked
just
out
of
the
box.
G
One
of
the
things
that
you
know
we're
working
on
right
now
is
shrinking
the
binary
size.
So
it's
a
it's
a
rather
large
binary
size,
unfortunately,
that
I'm
getting
yelled
at
at
work
to
kind
of
help
rectify.
Maybe
I
can
get
some
advice,
perhaps
at
some
point,
but
it
was
actually.
It
actually
was
actually
quite
easy
for
us
to
kind
of
work
up
the
configurations
to
kind
of
make
these
things
very.
You
know
DOCSIS,
ish
or
cable
like
so.
G
There
are
options
that
must
be
transmitted
as
part
of
the
DCP
six
transaction
that
allow
for
us
to
provision
these
devices.
One
of
the
things
that
we
did
notice
and
we
try
to
you
know
we
I
think
we
tried
and
refrain
from
hacking.
Diddler
is
when,
when
dibbler
does
a
proper
shutdown,
it
sends
a
release
that
was
actually
causing
some
some
issues
for
us
on
the
provisioning
side
of
things.
G
So
one
of
the
things
we
talked
about
was
modifying
the
kind
of
the
the
the
implementation
control
script
is
to
simply
kill
mine,
the
process
which
would
prevent
the
release
from
being
sent.
But
that
was
we
don't
do
that
because
it
was.
It
was
not
friendly.
So
one
of
the
things
that
we're
looking
at
doing
so
I'll
kind
of
pause
there
to
see.
G
So
one
of
the
things
we're
looking
at
now
with
DSP
p6
is
really
trying
to
optimize.
We
have
I
mean
if
you
think
about
the
math
that
I
just
told
you
right,
yeah,
there's,
probably
we're
probably
approaching
a
hundred
million
bindings
in
our
DSP
platform,
and
you
know
this.
This
server
platform
there
happens
to
be
somebody
yeah,
both
multiple
people
in
the
room
here
who
know
about
that.
G
So
what
we're
so
now
every
day
is
a
first
at
Comcast
and
and
what
I
mean
by
that
is
every
day
is
a
first
new
record
right
of
number
of
v6
devices
on
our
network
right.
This
yeah
we
reached
his
first
first
last
last
June
and
then
every
day
from
this
point,
four
is
basically
brand
new
another
another
kind
of
new
day.
So
what
we're
finding
is
is
that,
with
the
increase
in
these
number
of
devices
and
the
number
of
transactions
right,
because
every
DC
client
it
performs
reliefs
release
at
some
interval.
G
Sorry
renew
at
some
interval
many
of
devices
actually
do
it
every
day
right
so
where
we
are
now
is
we're
looking
to
really,
you
know,
would
that
with
the
growth
that
v6
has
really,
it
really
enabled
us
to
pursue.
It's
unencumbered
us
from
that
point
of
view
right
we've
been
able
to
add
many
more
devices
because
of
u6.
As
a
result,
the
scale
is,
is
now
almost
doubled
over
the
past.
G
You
know
ten
years
so
now
we're
we're
looking
at
opportunities
to
kind
of
really
optimize
these
be
these
p
v6
and
one
of
those
optimizations
is
perhaps
going
down.
The
path
of
stateless
TTP,
six
haven't
haven't
done
anything
more
than
just
some
kind
of
some
unit
testing
and,
frankly,
there's
some
people
back
back
at
the
office
that
deserve
all
the
credit.
G
Unfortunately,
that
does
not
involve
either
diddler
or
our
use
of
CR.
Today,
the
DCP
server
is
embedded
within
the
within
the
the
wireless
aggregation
device,
but
it
still
should
be
of
interest
to
you
guys
as
well
right
so
with
that
I
think.
That's
my
last
slide.
Anything
that
you
want
me
to
touch
on
before,
like
we
take
questions.
F
G
Your
home
readers
that
one
yes
yeah,
that's
a
good
one,
though
that's
I
appreciate
bringing
up
that
point.
We
we
had
some
bugs
to
fix.
We
are
in
the
process
of
implementing
sub
prefix
delegation.
I,
don't
know
if
that's
really
ever
been
a
topic
that
you
guys
really
wanted
to
needed
to
a
warrant
to
get
in
cuttin,
and
you
know
involved
with.
It
was
a
little
bit
of
a
knife
fight
in
kind
of
the
combination
of
v6
ops
and
in
particular
home
net.
But
it's
it's
gonna
happen.
G
H
G
G
G
And
wide
you
know
it's
either
a
bunch
of
it's
either
a
bunch
of
like
so
like
at
that
point,
just
full
disclosure.
We
would
in
the
situation
like
that,
the
home
router
would
get
a
56
absolutely
right,
and
then
we
would
either
do
like
58
or
60s.
Oh
yeah,
honestly,
this
days
of
the
game.
We
have
enough
experience
with
it
to
know
that
this
whole
idea
that
people
are
gonna
want
like
254
64
is
in
their
house.
G
H
64
and
I'm
not
putting
the
PIO,
it
still
blows
my
mind,
I
mean
yeah,
it
happens,
it's
bad!
It's
we
get
them
all
the
time.
The
other
question
was
you:
do
any
stateless
or
is
all
your
stuff
stateful?
You
always
use
DHCP
and
all
these
deployments,
the
staple
version
you're
never
giving
out
options
in
the.
G
Home
yeah
in
the
home
there
should
be
stateless,
D
to
be
b6.
Okay
in
the
access
network
always
stay
always
I
mean
yeah.
Yeah
I
mean
that's
the
way.
That's
the
way.
Dsp
was
born
and
cables,
and
that's
you
know
it's
the
shortest
distance
between
two
points.
There
was
for
us
to
just
kind
of
keep
going
the
same
thing
yep.
G
Do
you
have
stats
on
how
many
hosts
use
their
RDS
ue6
stateful
assigned
address
I
mean
you
do
support
stateful
internally
in
the
home
network,
where
you
don't
not
I,
don't
want
to
say
University
raised
because
we
have
a
mix
of
implementations.
Slack
is
everywhere.
Are
you
this
test
is
everywhere
right?
G
Point
that
I
realized
recently
is
that,
depending
on
the
size
of
the
pool
that
these
things
have,
they
can
end
up
being
like
privacy
issues,
because
they
don't
change
if
they're
like.
If
you
have
a
host
that
prefers
DHT
v6
assigned
address,
I,
don't
know
what
typical
has
then
it
becomes
very
important
how
big
the
size
of
the
pool
that
the
Gateway
has
and
how
often
it
changes
the
event
like.
B
G
Answer
that
I'm
about
to
offer
you
that
so
basically
what
one
of
the
things
I
know
that
we
did
is
we
went
from
the
last
so
0,
0,
0,
2,
FF
FF
is
the
pool
right,
so
65,000,
yeah
yeah,
so
I'm,
not
I'm,
not
a
huge
fan,
so
I,
rather
almost
just
turn
it
off
right.
That's
kind
of
dangerous
yeah
I
mean
it's:
it's
not
good
for
privacy
because
it's
likes
trivial
to
scan
that
number
of
addresses
yeah,
but.
G
Built
that
off
of
a
document
that
I
wrote
eight
years
ago-
oh
okay,
yeah
I
mean
it
was
just
just
active,
predates
62
or
whatever
it
was,
and
other
crap
like
that,
because
you
could
make
it
from
my
book
one
to
do
here.
So
we
had
to
go.
We
had
a
business,
we
have
to
like
chop
chop,
move
along
right,
so
so
we
kind
of
just
moved
on
without
it's
also
the
it's
also
the
quest.
It's
also
the
case
that
its
rotations
important
too,
even
if
you
did
rotate
it
all
right.
G
You
know
yeah
now
you
know
it's
not
with
these
keywords.
Dude
right
that
gateway
will
continue
to
renew
that
address,
for
as
long
as
the
upper
64
will
change
that
the
lower
support
could
change.
But
my
guess
is
most
clients
to
put
their
old
address
in
it'll,
be
a
hint
to
the
server
and
then
it'll
it'll
help
to
see
whatever
there's
new
allocation
is
so
so
then,
so
then
we
need
to
make
sure
that
implementations
are
preferring
other
addresses.
Yeah
I
mean
I,
think
yeah
yeah,
that's
something
that
you
mentioned
in
passing
here
this
one.
G
H
It
has
to
do
with
a
default
address
selection,
so
they
do
algorithms,
it's
it's
kind
of
out
of
the
box.
You
don't
you
don't
quite
know
what
you're
gonna
get.
It
does
vary
a
little
bit
but
yeah.
It
depends
on
the
address
scheme.
Most
of
some
of
them
will
choose
privacy.
Privacy
address
over
the
41
ninety-one
address,
but
if
they're
not
doing
that,
then
it's
a
crapshoot
I've.
G
That's
that's
the
thing
I'm
getting
at
here
and
before
you
have
the
fad
right,
and
so
your
address
is
nota
mised,
but
in
you
know,
but
nv6
somebody
can
just
like
track
you
using
the
last
few
but
understood
I
I'd
like
to
have
that
conversation
with
you
lorenzo
and,
if
you're
looking
to
have
some
collaboration
era,
I'm
open
to
that.
I
like
the
idea
of
kind
of
specifying
the
kind
of
the
pitfalls
of
having
a
very
narrow
base
for
address
allocations.
G
On
the
flip
side.
I
have
concerns
right.
So
like
one
of
the
things
we're
noticed,
and
it's
not
that
different
with
with
with
slack
privacy,
I
want
to
make
sure
that
we
don't
explode
the
impact
on
the
neighbor
tables.
Right
like
this
is.
This
is
a
serious
concern
that
I
have
no
I've
seen
this
blow
up.
So
my
gateways
already
right,
ralphe
ralphe
drums.
J
Still
living
the
dream
amen,
the
question
was
about
temporary
versus
permanent
addresses.
Do
you
have
any
idea
whether
clients
ask
for
temporary
permanent
what
they
I
mean?
That
was.
That
was
our
intention
when
we
originally
came
up
with
that
division,
but
I
have
no
idea
whether
whether
any
clients
actually
make
that
distinction
and
use
use
them
as
they
were
intended.
That
is
the
permanent
address
for
incoming
incoming
and
temporaries
for
outgoing
I've
even
lost
that
in.
E
G
F
Help
I'm
touring
across
key,
so
I'd
like
to
present
to
what's
been
happening
with
the
secure
DCP.
Recently
I
am
NOT,
echo
out
or
I
just
tried
to
move
this
work
forward
and
been
mostly
unsuccessful
with
this,
so
epic
of
history.
So
this
draft
or
its
predecessors
we're
around
for
quite
a
long
time.
We
went
through
last
call
in
March.
There
were
several
reviews
in
general.
They
were
favorable.
They
said
that
the
draft
has
improved
in
terms
of
clarity
and
completeness
in
quality
was
good.
F
However,
the
major
issue
rised
was
that
there
are
no
existing
implementations
so,
and
this
draft
is
quite
complex,
so
people
are
uncomfortable
with
moving
this
draft
forward
and
then,
after
a
while
a
primary
author
recently,
she
disappeared
and
stopped
responding
for
males
for
for
couple
months.
Fortunately,
she
got
back
like
two
days
ago,
but
she
missed
a
lot
in
the
process,
so
we
hope
that
the
issue
could
be
addressed
with
having
a
canal
in
Prague.
F
However,
and
shortly
after
the
hackathon
was
announced,
we
discovered
that
there's
a
problem
that
I
got
me
used
to
to
sign
the
packet,
as
has
the
problem
with
the
limitation.
So
it's
it
was
too
small
for
for
some
of
the
these
three
packets
so
and
after
that,
long
discussion
and
shoot
and
people
stepped
back
and
try
to
ask
the
basic
question.
So
what
are
the
problems
we
are
trying
to
solve?
F
And
these
are
some
of
the
ideas
that
were
mentioned
so,
as
you
can
see,
this
is
you
know
a
very
broad
spectrum
of
things
that
people
could
consider
in
in
general
when
you
think
about
security
and
DHCP,
so
lots
of
issues
lots
of
technologies
trying
to
solve
different
problems.
So
we
thought
that
ok.
So
this
is
not
exactly
going.
You
know
towards
completion,
so
we
stepped
back
and
talked
about
what
what
are
the
the
problems
that
we're
trying
to
solve.
So
we
had
a
meeting
Constantine.
F
So
all
the
outers
and
people
who
are
involved
that
commented
they
were
invited.
Only
only
four
people
showed
up.
We
went
through
different
use
cases
and
suddenly
the
conclusion
was
that
it's
probably
dead.
It
means
current
form
and
after
that
we
also
had
a
chance
to
talk
with
Kathleen,
who
is
a
security
ID,
and
she
suggested
that
we
could
consider
different
options.
One
of
them
would
be
to
publish
this
as
experimental
another
one
would
be
to
trim
it
down
to
cover
just
the
opportunistic
encryption
as
a
way
to
mitigating
pervasive
monitoring
attack.
F
So
during
the
discussion
we
tried
to
define
what
are
the
use
cases
that
this
just
could
address.
So
the
first
one
is
the
corporate
network,
so
you
have
devices
that
are
trying
to
connect
to
the
today
in
corporate
network
and
but
then
exactly
no
people
jumping
up
and
down
waiting
for
this
waiting
to
develop
the
solutions
and
deploy
it
in
in
corporate
networks,
and
we
strongly
believe
that
the
reason
is
that
you
can.
F
You
can
protect
the
first
hope
with
802
and
dot
1x
when
we're
talking
about
communication
between
the
client
and
the
relay
and
between
the
relay
and
the
server
can
be
protected
with
IPSec.
There
are
also
other
technologies
that
can
help
with
this
environment,
for
example
the
HP
v6
shield.
So
another
use
case
that
was
frequently
mentioned
is
the
coffee
shop.
So
you
have
your
your
device,
you
come
to
a
coffee
shop,
you
don't
exactly
know
them,
but
you
would
like
to
use
the
internet
so
the
tofu
trust
of
unfused
use
model.
F
It
was
mentioned,
suggest
agent,
but
when
you
at
first
glance
it
it
sounds
good.
But
if
you
take
a
closer
look,
it
really
doesn't
hurt
that
much.
So
it
helps
a
bit
with
pervasive
monitoring
in
the
sense
that
that
you
could
encrypt
the
traffic.
But
actually
you
don't
know
who
you
are
connecting
to
so
whether
you
are
connecting
to
the
right
server
or
maybe
rope,
server
and
also
the
argument
that
ok,
so
it
helps
with
providing
monitoring.
But
if
the,
if
the
server
is
participating
in
the
monitoring,
you
are
out
of
luck
anyway.
F
So
people
came
up
with
some
ideas
that
ok,
maybe
you
could
put
some
stickers
like
you,
go
to
coffee
shop
and
you
scan
the
QR
code
and
then,
based
of
that,
you
can
confirm
whether
this
is
the
right
or
or
bogus
server.
But
this
is
very
easy
to
circumvent.
Someone
can
go
in
and
stick
new
sticker
on
top
of
it,
so
it
doesn't
help
a
lot
so
in
the
last
use
case
that
we
have
is
inside
their
attack
in
corporate
network.
So
this
is
something
that
that
threat
is
very
interested
in.
F
So
the
idea
is
that,
okay,
you
are
using
802
1x,
so
you
are
authenticated
to
use
the
network,
but
then
you
can
impersonate
someone
else
like
to
elevate
your
privileges
or
cover
your
tracks
and
also
in
the
discussions.
One
of
the
slightly
uncommon
use
case
was
mentioned
that
if
this
would
ever
be
deployed
in
a
military,
this
could
be
used
when
someone
steals
the
device
and
gets
access
to
the
network,
it
can
broaden
the
impact
of
the
attack.
F
So
these
are
the
use
cases
that
we
considered.
So
ok,
given
all
that
I
think
I
covered
all
the
aspects
of
the
discussions
that
we
recently
had.
So
now,
I'd
like
to
consider
what
are
the
next
steps,
so
first
we
could
fix
the
problem
with
signing
the
with
the
with
the
encryption
size
limitation.
There
are
some
known
techniques
for
that,
and
then
we
could
publish
this
as
experimental.
F
F
The
tip
the
possibility
is
to
work
on
a
problem
statement
first,
so
basically
step
back
and
agree
on
what
are
the
problems
that
we
need
to
solve
and
then
deliver
a
solution
that
solving
only
those
problems
and
final
option
is
to
drop
the
work.
So
I'd
like
to
ask
you:
what
are
your
opinions?
What
are
your
preferences.
B
You
know,
and
also,
if
there's
a
general
discussion
on
any
of
the
you
know
things
that
I
presented
earlier
people
have
follow-up
questions
around
some
of
the
things
that
that
we
talked
about
we'd
love
to
to
hear
those
so
Tim.
H
One
airshow
nhi
well
I
vote
opportunistic
encryption
on
this
one,
hey
I,
also
be
okay.
If
we
want
to
go
back
and
look
the
problem
statement,
I
think
you
know
I
think
we're
gonna
have
problems
if
we
don't
work
on
this
problem
and
it's
people
are
gonna,
look
at
3315
biz
and
wonder
where
the
security
stuff-
and
we
can
at
least
tell
them
we're
working
on
it.
I
think
one
of
those
two
works
I
think
dropping
the
work
and
just
walking
away,
probably
isn't
gonna
work.
Yeah.
F
F
K
Fred
Templin
Boeing,
so
so
what
I
need
is
is
really
a
very
simple
thing:
I
need
a
way
for
the
client
to
authenticate
itself
to
the
server,
so
I
don't
need
to
have
all
the
encryption
and
all
the
you
know,
the
other
stuff
that
would
come
at
this.
So
how
would
that
work?
What
I'd
have
to
write
my
own
little
thing
or
what
would
it
be
an
extension
of
3315
to
do
just
a
client
authentication
so.
F
It
depends
there
are
couple
options:
the
3315.
This
still
has
the
authentication
option
and
and
there's
a
registry
of
algorithms.
So
you
could
write
this
very
simple
job
that
you
asked
for
a
new
assignment
assignment
of
a
new
value
in
that
and
then
define
your
algorithm
for
for
doing
that
or,
alternatively,
you
could
use
the
parts
from
from
the
from
the
existing
draft,
but
I
think
going
quit
using
the
authentication
option
would
be
simpler,
okay,
okay,
that
makes
great
sense.
Thank
you.
L
Consider
po
I
say:
if
we
have
some
hustles
to
do
new
work,
we
should
go
directly
to
the
problem
statement
because
from
the
beginnings
one
of
the
program
of
the
security
CP,
this
exam
was
to
have
no
problem
statement
so
kind
of
solution.
I
was
very
news
about
this
part
and
I.
Give
you
one
of
the
source
of
the
final
situation
where
we
are
so,
if
you
have
soy
sauce
put
it
in
a
form
statement:
okay,.
C
B
L
B
B
More,
no,
it
was
more
bad.
You
know
the
forethought
from
which
you
drop
the
work,
which
is
obviously
we
can
all
agree
that
that
we
know
what
that
means
right.
The
problem
statement
might
end
up
that.
We,
you
know,
we
don't
know
you
know
or
I,
look
at
it
more
as
a
requirement
statement.
You
know
what
do
we
require
that
a
problem
statement,
because
I
think
it
should
be
sort
of
the
combination
of
the
two
to
say
what
are
the
problems
that
we're
trying
to
solve
and
therefore
what
are
the
requirements?
F
B
I
guess
there's
also
question
about
you
know
we
haven't
had
that
much
discussion
and
we'll
have
to
take
anything
that
we
do,
of
course,
of
the
mailing
list
to
just
sort
of
confirm.
But
I
guess
we,
you
know
if
there
is
a
consensus
in
the
room
that
would
be
useful
and
so
I
guess
we
should
go
through
the
four
options
and
ask
how
many
people
are
in
favor
either
in
terms
of
a
home
or
a
hand-raising
and.
I
M
B
M
It
would
solve
the
airport
use
case
like
I,
don't
use
wireless
at
an
airport.
We
also
have
I
Triple
E
doing
things
like
standardizing
the
function
to
randomly
assign
MAC
addresses
right,
they're
going
to
that
kind
of
trouble,
and
we
can't
even
do
this
very
basic
level
of
encryption
at
the
very
next
step
right.
So,
if
you
think
about
like
the
fruit
they're
picking
off
we're,
not
picking
off
the
fruit
that
we
can
be.
L
L
C
F
I
F
L
M
So
Kathleen
we
already
set
KD
again
to
comments
on
that,
so
encryption
would
help
to
make
it
be
an
active
attack
to
be
able
to
look
at
whether
or
not
that
function
is
in
use,
and
my
other
question
is:
how
often
is
that
ability,
understood
and
used
by
deployers
of
airports,
networks
and
coffee
shop
networks?
Well,.
B
B
Nothing
that
the
server
would
have
to
do.
Obviously
there
is,
you
know
if
the
client
changes
its
its
addresses
very
frequently.
Its
MAC
addresses
very
frequently
and
also
therefore
changes
its
its
client
identifier
that
it
presents
to
the
DHCP
server.
It
would
have
to
change
his
hat,
because
if
the
lease
is
still
active,
so
the
idea
would
be
that
you
go
into
one
airport.
You
might
get
MAC
address
a
and
client
identifier
a
and
then
you
go
to
a
different
Airport
and
you
know
you
would
connect
differently.
M
So
I
guess
I
would
like
I
still
would
like
to
see
opportunistic
encryption
as
a
possibility,
as
just
the
lowest
possible
thing
you
can
do
to
ensure
that
it's
just
active
attacks
I
would
either
get
at
this
level.
You've
done
seven
years
of
work
on
this
and
to
throw
away
the
idea
completely.
Just
yeah
I
mean.
D
M
F
F
F
B
F
B
M
All
right
there's
a
lot
of
expertise
in
the
IP
second.
F
B
B
B
Relay
you
know,
we
don't
want
to
replace
the
relay
agents,
and
so
we
need
a
protocol
that
really
works
at
the
DCP
layer,
because
the
relay
will
forward
DHCP
packets
for
us
and
there's
a
mechanism
to
do
that.
And
so
we
really
need
something
that
works
at
the
DHCP
layer,
because
we
can't
do
it
at
the
IP
layer
unless
we
do
hop-by-hop
and
the
problem
with
hop-by-hop
is
that
you
know
that
that
I
mean
that
could
be
an
option.
H
So
the
IPSec
will
work.
Fine,
it's
the
key
exchange.
It's
the
the
key
exchanges,
the
whole
problem
here,
an
IEP
to
the
multicast
thing
is
gonna,
be
you
know
they
tried
to
do
this
in
routing
protocols
and
did
not
have
a
lot
of
success
with
Karp
III
think
we
should
go
talk
to
them
and
I.
Think
it's
a
conversation
we
can
have
saying.
This
is
our
use
case
for
a
first
hop
you're
gonna
have
to
talk
about.
The
IPSec
will
work.
Fine.
You
can
put
any
rule
you
want
in
there
like.
H
H
Have
to
exchange
I'd
have
to
think
about
this
Tim
when
Tim's
better
at
this
and
I
mean
this.
Is
why
Tim's
suggesting
you
know
he's
worked
with
the
IPSec
working
group
for
some
time.
He
obviously
does
all
the
v6
IP
sex
testing
that
we
do
at
the
lab.
He'd
be
that
kind
of
stuff.
If
you
want
to
talk
details
he's
the
guy,
you
want
to
talk
to
Mike
and.
L
We
already
answers
came
up.
The
discussion
find
Sansa
I
heard
some
help
about
the
pur
Couture
part
to
see.
If
there
is
something
usable,
we
have
a
lot
of
hard
things
to
adapt
disappea
to
do
securities,
you
can
go
to
one
exchange
with
me
together
twist
a
nightmare.
Of
course.
You
have
no
address,
so
you
can
choose
any
stone
de
her
security
protocol.
So
we
already
go
on
this.
N
Okay,
so
descrition,
and
so
and
there's
one
thing,
I
want
to
say
here
so
drop.
The
work
is
okay
with
me,
given
that
okay,
so
if
you
decide
to
go
that
way
like
33
15,
biz
has
to
probably
do
something
more,
so
you
cannot
use.
A
cuts,
does
doesn't
exist
right
like
so,
and
so
I'm
fine,
with
working
on
the
problem
statement
like
do
opportunistic
encryption
is
okay.
N
I,
asked
explicitly
call
first
sector
review
for
this
like
couple
of
meetings
ago
right
because
this
was
obviously
a
security
thing,
but
I'm
I'm
talking
about
doing
the
security
review
for
3315
this,
which
is
like
a
huge
document
but
I,
think
it'll
take
some
effort.
But
if,
like
you
know,
caffeine
can
come
back
with,
like
you
know,
review
of
it
saying
like
hey
guys
like
you
need
encryption
here
or
is
it
on.
N
M
M
M
N
F
N
B
O
B
N
B
N
B
But
I
mean
yeah
I
mean
it's
just
the
process
of
going
through
this
review,
the
security
reviews
and
stuff
like
that,
okay,
which
we
should
be
able
to
do
fairly
soon,
so
it's
it
may
not
really
delay
things
that
much
and
it's.
If
somebody
really
is
an
interest
on
one
of
these,
you
know,
isn't
drop
the
work.
They
can
start
the
work
yeah.
So,
okay.
B
B
Okay,
all
right
so
I
think
unless
you
know
that's
what
I
mean.
Does
anybody
have
any
feelings
about
that?
That's
a
bad
direction.
Does
they
may
want
to
so
so
I.
Just
to
summarize
I
think
we're
going
to
do
now
is
wait
to
see
what
happens
with
the
security
privacy
analysis
of
3315
bills
to
see
if
there
is
a
problem
that
we
still
need
to
solve
and
based
on
that
result,
we'll
have
to
figure
out
what
we
do
with
the
work.
P
P
C
B
I
I
I
Now
this
is
used
to
manage
the
devices
and
to
collect
the
data
from
the
devices
for
such
cases
and,
as
you
all
know,
did
CP
v6
is
still
popular
in
mayate
networks
to
get
the
fixes
and
IPS
of
course.
So
we
realize
that
that
is
need
to
support
some
options
to
enable
every
services
I
would
hear
any
devices
these
options
have
acquired
in
dhcpv6.
Of
course,
we
thought
of
proposing
same
for
p4
also
to
negative
life,
that's
it
so
that
can
be
more
easily.
I
So
a
library
Shinto
mission
protocol
is
a
specification
defined
in
Open
Mobile
Alliance,
a
device
management
vendor
data
collection.
It's
a
client-server
protocol,
just
like
any
other
claims,
I'm
gonna
call
it
works,
and
this
runs
on
constrained
application
protocol,
which
is
IETF
RFC,
seven,
two
five
two.
So
this
constraint
application
protocol
provides
service
for
end
of
this
just
like
HTTP,
except
that
it
runs
from
UDP
to
make
it
lightweight.
So
now,
if
you
see
this
diagram
lightweight
mission
to
Mission
client
managers,
some
data
objects.
I
Obviously
those
data
objects
are
nothing
like
the
data
that
we
want
to
exchange
in
Iwate
scenarios
by
example.
Maybe
the
location
of
the
device
temperature
humidity,
this
den
of
objects
are
defined
in
is
what
objects,
and
you
can
see
two
different
servers
here.
One
is
boots
webserver
and
the
other
one
is
actual,
like
recognition,
Commission
medical
management
server,
so
the
boots
web
server
is
the
one
which
is
used
to
push
up
the
client
device
and,
during
the
most
traffic,
provides
the
information
that
is
required
to
get
connected
with
the
actual
management
server.
I
So
doing
boots
fabric
provides
information
like
management
server,
maybe
the
URI
required
to
connect,
and
also
some
security
credentials
or
certificate.
Such
things
also,
but
the
whole
problem
which
we
are
talking
here
is
the
bootstrap
server
information
itself
is
hard-coded
on
is
manually
configured
today
on
aw
my
devices.
I
I
Okay,
in
summary,
and
what
we
are
proposing
is,
as
I
said,
the
bootstrapping
server
information
is
are
coded
or
manually
configured
today
at
the
client
devices.
So
we
see
need
for
the
few
options
require
four
of
them
in
the
two
of
them.
They
are
appended
February
406.
Here
one
is
the
UI
itself
which
is
required
to
get
connected
with
the
source
web
server.
We
can
use
dhcpv6
option
this
one,
then
the
second
one
is
the
certificate
that
is
required
to
connect
with
the
first
our
server
the
same.
I
I
I
I
mean
the
standard
format,
it's
a
string
that
we
use
it's
not
an
ultimate
extreme,
so
how
to
input
this
URI.
It's
already
mentioned
in
our
options
related
or
axis,
which
is
provided
in
that
I
dropped
as
a
reference.
So
can
we
move
on
to
the
next
one?
So
the
next
one
is
a
LW
MDM
server
certificate.
That's
required
to
get
connectivity,
so
here
there
are
few
issues
have
two
concerns
arise
which
I
am
trying
to
address.
One
is
about
validating
the
certificate
itself.
I
L
Facility
paw
oops.
L
I
L
So
force
is
upon
so
I
sent
an
email
on
Solis
because
I
believe
lasted,
not
about
so
I
agreed
to
agree
to
sell
torpedoed,
which
is
section
free.
That
six
is
the
specified
and
I
propose
some
improvements,
so
it
can
just
read
the
list
on
discuss
with
me.
If
you
mean
you
have
multi
tests
or
you
need
something
else,
yeah.
I
Okay,
I
will
referring
some
more
about
the
encoding
formats
liking.
The
comment
I
will
refer
this
RFC
and
update
this,
and
the
next
one
is
of
course
again
the
bootstrap
URI
24option
structure.
Again
I
am
not
happy
about
it,
it's
stranded
one.
So
maybe
we
can
already
move
the
next
about
it,
and
here
we
are
again
the
certificate
that
we
want
to
use
puppy
for
clients.
I
There
are
some
concerns
expressed
about
this
also
about
the
size
of
the
certificate
itself
might
be
very
big
and
we
can't
accommodate
it
in
the
private
option,
as
this
was
already
a
comment
I
received
from
me,
and
they
also
suggested
to
use
some
other
reference
where
one
of
the
autopsy
talks
about
how
to
import
bigger
options
in
TV
for
options.
So
I
mentioned
that
already
in
the
draft-
and
this
is
also
common
I
received
today
from
France
if
I'm
not
wrong,
so.
I
I
There
are
new
comments
which
I
received
today
and
on
them
of
course,
and
the
one
more
important
thing
is
I'm
sure
there
might
be
two
other
people
working
on
this.
I
OTE
just
kissed
since
in
I
use
I
would
like
to
know
if
there
are
more
those
cases
where
someone
drops
be
quiet
so
that
we
can
pour
that
when,
when
draft
on
document
so
that
it
covers
all
I
would
be
related
scenarios
at
least
known
I
would
be
billeted
scenarios,
if
not
all
so.
I
B
Okay,
this
is
Bernie
volts.
A
few
questions.
You're
on
you
mentioned
that
most
most
IOT
stuff
is
using
v6
and
I
know
you
could
define
v4
options,
but
if
nobody's
gonna
use
them,
it
may
be
better
not
to
do
them,
because
the
v4
option
space
is
a
little
tighter
I
mean
you
know,
maybe
v4
is
dead
and
we
don't
have
to
worry
about
it.
But
you
know
just
a
question:
I
mean
it
may
be
better
if
you
don't
need
them
to
just
remove
them,
because
you
know
it
just
preserves
that
resource
I.
I
Understand
that
point,
but
I
wanted
to
reverse
this,
because
when
we
see
the
devices
that
are
coming
in
to
properly
market,
we
see
one
statement
in
support
a
journalist.
They
say,
as
of
now
I
am
a
poor.
Ipv6
will
be
supported
later.
This
is
the
kind
of
statements
we
keep
listening,
so
maybe
whether
such
devices,
which
are
still
not
completely
ready,
maybe
we
can
still
use
me
for
that.
The
reason
why
I
wanted
to
keep
it,
of
course,
as
you
said,
India
Cherokee,
nobody
is
view,
is
going
to
use
v4
at
all.
I
In
any
scenario,
then,
yes,
I
think
we
can
skip
it
and
also
when
my
point
is
maybe
in
industrial
automation,
kind
of
cases
where
a
polite
way
to
the
mission
protocol
is
running
I'm,
not
sure
whether
they'll
completely
go
for
me
for
or
they're
still
use
they
own
internet
with
sorry,
they
will
go
for
me
fix
whatnot.
They
might
use
their
own
internet
v4.
It's.
B
Okay,
you
know,
if
you
don't
need
it,
don't
ask
for
it,
but
if
you
think
you
do
that's
fine,
I
I
think
they
also
follow
the
rc7
2
to
7
guidelines.
So
you
know,
there's
not
really
much.
We
comment
on
the
question
about
doing
an
adoption
call
really
goes
to
Suresh
and
the
question
about.
Is
there
a
you
know
there?
There
probably
is
no
other
working
group
that
would
cover
this
technology
and
therefore
it
really
does
fall
back
to
us
and
as
long
as
you
know,
Suresh
is
in
favor
of
us
doing.
N
I
N
So
so
I
don't
mind
like,
but
as
long
as
like
make
sure
there's
like
you
know
somebody
to
review
this
here
and
I'll
try
to
find
review
outside,
but
I.
My
only
concern
would
be
like
whether
this
will
get
enough
review
here
so
like
we
can
look
at
the
option
formats,
but
the
content
itself
I'm
not
sure
how
we
can
get
review
here
so
like.
Maybe
we
had
to
figure
out
how
to
do
that.
But
I
don't
mind
if
you
are
out
this
and
like
we'll
figure
out
how
to
do
that.
If
there.
I
N
N
B
Q
R
H
R
Okay,
regarding
the
DMM
stuff,
we
are
reviewing
that
in
DMM,
okay,
so
a
very
quick
description
of
what's
happening
in
DMM,
and
we
are
talking
about
mobile
networks
so
in
mobile
minute
networks.
One
of
the
problems
that
we
have
is
to
maintain
IP
session
continuity
while
a
node
travels
around
the
network.
R
R
R
R
Solution
that
we
are
trying
to
define-
and
there
is
another
solution
or
another
way
of
looking
at
things,
so
if
you
think
about
it
before
I,
try
to
explain
why
I
see
continuity
is
important,
but
really
some
applications,
don't
really
need
IP
continuity.
They
could
manage,
managed
very
well
a
modification
of
their
source
IP
address.
They
will
reopen
a
socket
with
a
new
IP
address.
The
user
experience
won't
be
really
affected
and
everything
works
well.
R
R
Maybe
I'll
just
describe
to
one
is
session
lasting
IP
address.
Such
an
IP
address
is
guaranteed
by
the
network
to
be
valid
as
long
as
the
session
is
still
running.
This
is
excellent
service
from
the
network
and,
of
course
it
requires
the
tunneling
and
it's
costly
and
the
other
one
I
want
to
describe
here
is
non
persistent.
Non
persistent
means
no
guarantee,
you
are
getting
an
IP
address,
it
might
go
away.
You
will
have
to
deal
with
that,
and
I
showed
that
there
are
patience
that
can
deal
with
that,
of
course,
for
session
last
thing.
R
We
need
a
mobility
anchor
or
an
LMA,
and
for
non-persistent
we
don't
need
okay.
So
actually,
in
the
draft
that
I
referenced
in
the
mailing
list,
we
introduced
two
new
options.
We
tried
to
limit
the
changes
that
we
are
requesting
from
DHCP.
We
are
not
experts
in
DHCP
and
we
didn't
want.
We
don't
think
we
need
too
much
activity
in
DHCP
and
ok.
So
one.
R
R
R
So
an
example
for
the
IP
continuity
service
option
it
should
be
encapsulated
in
the
prefix
option,
options
area
of
the
prefix
delegation
option.
This
is
where
it
has
to
be.
I
am
trying
to
show
here
a
schematic
of
where
it
is,
and
it's
similar
to
the
status
code,
a
status
code
option
which
also
appears
in
that
options
area.
So
this
is
where
we
see
this
new
option
coming
in.
R
R
R
The
server
will
reply
using
this
option
only
when
it
initially
received
the
request
for
this
option
and
once
the
server
replied
with
this
option.
Any
subsequent
messages
which
are
related
to
this
prefix
should
use
this
option
and
should
not
change
the
value.
So
it's
not
like
I
requested
session
nesting,
IP
prefix
I
got
one
and
then
at
some
point,
I'm
trying
to
renew
the
lease,
but
with
a
different
type.
This
is
not
allowed
backwards
compatibility.
R
R
B
F
R
Community
service
options,
I
see
no
I,
see
okay,
so
I'll
fix
I'll
fix
the
text
in
the
draft
to
say
what
happens
in
that
case,
and
so
so
the
right
message
flow
is.
The
client
will
request
prefix
with
this
option,
will
receive
a
reply
without
this
option
and
will
deduct
that
the
server
doesn't
support
that
okay,
okay,
thank
you.
Okay,
so
I'll
fix
that
and
of
course
our
server
cannot
reply
with
the
prefix
with
that
option.
If
the
client
didn't
initially
request
that
object,
okay
again
for
backwards-compatible,
yes,.
R
F
I
see
you
have
a
comment
here
about
the
client
recording
the
information
that
the
server
doesn't
support
the
option.
It's
tricky
not
necessary.
The
client
could
continue
sending
this
option
in
following
messages
if
it
still
makes
sense
from
the
right
perspective,
because
there's
capability
could
be
an
ended
lighter
at
the
time
and
the
client
than
would
pick
it
because
otherwise,
when
you
visit
a
new
network
and
it
detects
that
okay
is,
this
ability
is
not
enabled,
and
then
it's
it
gets
an
a
bit
lighter.
The
client
would
never
be
able
to
detect
this
so.
R
B
O
R
To
think
I
think
that
in
the
text
in
the
draft
I
have
to
visit
that
I
wrote
that
subsequent
subsequent
messages
should
not
have
that
option,
but
every
once
in
a
while
it
can
introduce
the
option
again,
it's
probably
easier
just
to
say
said
always
exactly
especially
as
you're
saying
the
option
will
be
ignored.
I
wasn't
I,
wasn't
aware
that
the
server
will
ignore
it,
but
will
reply,
but
since
it
does,
maybe
this
makes
more
sense.
So
I
will
fix
that.
R
Okay,
oh
I,
didn't
talk
about
the
I,
want
to
talk
back
about
the
anchor
preference
option.
Okay,
what
is
an
anchor
preference
option
and
why
I'm
not
sure
we
need
it.
If
we
go
back
to
this
slide,
we
can
see
that
we
have
several
anchors
in
this
slide.
We
have
three
anchors
and
there
is
an
issue
of
how
does
the
network
allocate
a
specific
anchor
to
a
note.
B
R
Now
we
didn't
get
into
too
much
work
regarding
how
to
allocate
anchors,
not
yet
at
least
in
DMM,
but
I
was
requested,
but
by
one
of
the
delegates
to
enable
a
future
algorithm
where
the
node
knows
what's
best
for
him
and
will
ask
for
a
specific
anchor
now.
The
node
is
not
aware
of
anchors,
but
the
node
has
history
about
prefixes
it
received
in
the
past
and
if
it
comes
and
says
give
me
this
prefix,
it
actually
means
I
want
this
route,
this
LMA
or
this,
because
the
different
anchors
provide
different
prefixes.
R
So
we
thought
to
add
this
option
where
a
node
requests
or
hints
hey,
it'll,
be
nice.
If
I
get
this
this
prefix
meaning
this
is
the
LMA
I
want
or
the
anchor
I
want.
It
doesn't
necessarily
have
to
receive
this
specific
prefix,
but
it
wants
to
receive
a
prefix
from
that
LMA.
Okay,
now,
when
I
read
and
by
the
way
the
network
and
it's
written
there,
the
network
doesn't
have
to
provide
that
prefix.
It's
just
a
hit.
Now,
when
I
read
the
prefix
delegation,
draft
or
IRC
again,
I
saw
that
this
already
exists.
R
So
I
said:
hey,
maybe
we
don't
need
it,
but
the
interpretation
is
a
little
different
and
I
wanted
to
make
sure
that
it's
okay
or
whether
I
need
another
option.
The
interpretation
that
I
understood
from
the
RFC
is
when
a
note
requests
a
certain
prefix.
It
wants
that
certain
prefix
and
what
we're
saying
here
is
when
we
hint
on
that
prefix,
we
will
be
satisfied
with
any
prefix
associated
with
the
same
enemy,
I
I.
B
B
Probably
not,
you
know,
doesn't
know
so
right,
because
I
think
you
don't
need
a
new
option
to
just
you
just
request
the
client.
You
just
have
the
client
request
that
prefix
and
then,
if
the
server
gives
it
that
prefix
or
gives
it
some
other
prefix,
it's
really
up
to
the
server
to
determine
what
meaning
that
has
right.
R
B
R
L
L
B
R
In
here,
which
is
very
helpful,
so
I
will
pretend
I'll
read
33:15
this
and
then
I
will
issue
a
new
version
of
the
draft
and
I'm
getting
to
next
steps.
So
so
I
will
probably
be
happy
to
receive
another
review
on
that
new
draft,
just
to
make
sure
that
I
captured
the
comments
correctly
and
that
I
didn't
break
anything
and
if
I
get
a
V
from
DHC
I
can
go
back
to
the
mm
and
say
DHC
approved
that
we
can
continue
our
work.
Yes,.
B
And
I
think
if
you
know,
because
options
will
eventually
require
both
Sanders
action
and
expert
review.
You
know
some
of
the
people
that
are
viewing.
It
are
active
that
you
see
working
growth
will
get
a
review
at
that
point,
but
I
think
it's
still
better
that
whenever
you
make
a
change
or
like
when
you
go
for
a
working
group,
last
call
come
in
the.
I
B
N,
let
us
know
about
it,
because
that's
another
viewpoint,
so
if
you
make
any
substantive
changes,
you
know
I
mean
if
you're
just
republishing,
to
keep
it
alive
or
something
or
make
a
Natori
elaine's
no
big
deal.
But
if
there's
a
substantial
change
makes
notify
us
about
the
change
and
also,
if
you
go
to
working
group
last
call
include
us
in
the
working
group
last
call
cycle
just
so
that
we're
aware
of
it.
That's.