►
From YouTube: IETF113-6LO-20220323-0900
Description
6LO meeting session at IETF113
2022/03/23 0900
https://datatracker.ietf.org/meeting/113/proceedings/
C
C
There
is
some
sort
of
audio
issues,
maybe
yeah.
Now
it's
yeah.
Now
it's
better!
Thank
you,
okay,
so
things
as
you
can
see.
Well
the
chairs
and
the
80.
We
are
all
unfortunately
remote
this
time,
but
then
we
have
michael
richardson
as
our
delegate
in
the
room
thanks
a
lot
michael
for
helping
and
also
we
have
mida
takers
adnan
dominique
and
michael
who
have
kindly
volunteered
as
well
and
also
michael
will
be
our
javascribe
today.
So
thanks
a
lot
to
all
for
helping
and
volunteering.
C
C
C
That
has
some
in-person
component
so
for
in-person
participants.
There
are
some
tips
to
keep
in
mind.
Please
make
sure
that,
even
if
you
are
in
the
room
physically
make
sure
that
you
sign
into
the
session
using
miteco,
for
example,
by
using
the
lite
client
that
you
can
find
from
the
data
tracker
agenda,
as
in
fact
we
are
going
to
use
meet
echo
for
managing
the
cube.
C
So
you
need
to
use
neteco
to
join
the
queue
if
you
want
to
do
so,
there
is
a
single
unified
queue
and
also
blue
sheets
are
automatically
generated
from
miteco,
so
they
are
not
like
physical
blue
sheets
and
for
remote
participants
mechanism.
The
mechanics
are
like
the
the
same
as
in
previous
fully
online
meetings,
just
make
sure
that
your
audio
and
video
are
off
unless
you
are
presenting
next.
Please.
C
C
C
C
Okay,
so
if
there's
no
comment,
let's
proceed
to
the
next
slide.
Yes,
so
this
is
the
report
about
the
working
group
documents.
First
of
all,
since
the
last
atf,
we
have
a
new
rfc,
that's
9159,
about
ipv6
mesh
over
blinks.
So
congratulations
to
the
authors
and
many
thanks
to
everyone
who
has
contributed
in
the
process
by
giving
comments
and
reviews
and
so
on.
D
Yes,
thank
you.
I
think.
D
At
this
point,
basically,
I
I
need
to
I
need
to
double
check
with
lars,
real,
quick
and
then
just
schedule
it
for
to
bring
it
back
to
a
chill
chat
on-
probably
not
not
the
first
teletub
after
this
meeting,
but
late
april
or
or
may
so.
If
lars
wants
to
have
some
kind
of
a
second
last
call,
because
it
has
been
such
a
long
time.
We
might
need
to
do
that,
but
I'm
hoping
that
won't
be
the
case.
D
I
don't
know,
convey
whatever
people
need
to
know
to
feel
comfortable
that
everyone
who
needed
to
review
the
document
at
the
l2
l3
layer
interaction
had
access
to
the
definition
of
the
l2
layer.
So
but
that's
unfortunately,
yeah
it
has
not.
I've
not
been
able
to
make
it
a
priority,
but
I'm
catching
up.
C
Okay,
thank
you
for
the
update
so
yeah.
It
sounds
like
we
have
a
plan
for
next
steps
and
yeah.
Then
the
next
draft
that
has
been
also
evaluated
by
the
asg
is
the
draft
about
ipv6
over
plc.
C
So
actually,
what
you
can
see
on
the
slide
with
the
red
and
green
colors
is
like
not
up
to
date
anymore,
because
a
few
hours
ago
there
were
some
some
updates
here.
So
there
were
two
remaining
discuss
ballots,
however,
both
have
been
cleared
in
the
last
hours,
so
actually
one
of
them.
The
one
by
benjamin
still
has
a
set
of
comments,
and
the
authors
may
need
to
to
see
whether
they
still
may
want
to
to
address
them.
C
D
I
I
said
to
you
in
an
email,
but
I'll
say
it
here:
I
think
if
they,
if
the
authors
get
a
dash
11
that
incorporates
whatever
it
is,
they
want
to
incorporate
from
from
men's
comments.
That'd
be
great
and
I'd
be
happy
to
send
it
off
to
the
rfc
editor
from
there.
C
C
E
So
thanks
so
good
morning,
my
name
is
paolo
volpato.
Let's
say
that,
as
you
see
I'm
not
in
the
list
of
the
authors
of
this
draft,
I'm
presenting
on
the
alpha
of
the
authors
represented
here.
The
reason
why
I'm
here
to
talk
about
the
transmission
of
ipv6
packets
over
plc
networks
is
that
I
had
a
talk
with
my
at
huawei.
E
They
were
not
able
to
attend
itf
113,
so
they
asked
me
to
act
as
a
proxy
on
on
their
behalf.
So
to
update
you
about
the
status
of
the
draft
and
explained
by
the
chairs,
I
saw
a
couple
of
emails
yesterday.
I
think
which
to
some
extent
obsoleted
some
of
the
content
of
this
presentation
anyway,
we'll
discuss
that
and
we'll
see.
What's
the
reaction
so
next
slide.
E
Okay,
so
status,
you
see
here.
Basically
the
draft
underwent
the
last
call
review.
I
think
end
of
2020
tail
chat
and
isg
evaluation
happened
in
summer
2021.
E
I
got
three
discusses
one
from
eric
winker
and
I
think
that
was
let's
say
addressed
by
the
most
recent
versions
of
the
draft.
Specifically,
there
was
a
major
revision.
E
It
was
a
zero
nine
which
addressed
that
comment,
and
then
there
were
a
couple
of
discusses
that
probably
were
partially
addressed
by
the
list
is
the
versions
of
the
draft
one
from
roman
again,
apparently,
it
was
okay,
after
reviewing
version,
zero,
nine
and
that
was
completed
in
version
ten
and
the
let's
say
the
major
point
of
discussion
was
the
discuss
raised
by
benjamin,
but
I
said
that
happened
before.
Let's
say:
itf
113
there
was
a
email
sent
yesterday
which,
if
I
understand
correctly
reconsidered
the
text
provided
by
the
authors.
E
E
Okay,
let's
jump
to
the
discuss
provided
by
by
benjamin.
So
the
main
point
was
about
the
use
of
the
two
bits,
the
let's
say:
universal
local
and
individual
group
bits
in
the
first
byte
of
the
interface
ied.
So
basically,
the
issue
was
that
the
original
draft
imposed
those
two
bits
to
be
set
to
zero,
but
that
apparently
was
creating
some
issues,
so
that
originated.
E
Let's
say
they
discussed
by
benjamin.
The
authors
reviewed
that
position,
so
they
let
they
lose.
The
constraint,
which
was
described
in
version
0,
6
and
basically
provided
two
ways
to
deal
with
those
two
bits.
E
So
the
first
mode
was
to
let's
say,
use
those
two
bits
as
originally
intended,
so
maintain
those
bits
to
zero
when
forming
the
interface
id
or
the
other
mode
which
was
defined
in
the
version
10
of
the
draft
was
to
leave
to
the
operators
basically
to
use
freely
those
two
bits
without
taking
care
of,
let's
say
how
the
specification
set
them.
E
As
said,
that
was
the
slide
produced
by
the
autos,
the
the
the
last
comment
by
benjamin,
let's
say,
superseded
the
description
provided
in
that
slide.
So
next
one
michael
this,
then
there
was
a
comment
received
during
the
last
call
process
was
about
the
interface
id
entropy
again.
Originally
that
was
not
included
in
the
draft,
but
the
latest
versions,
let's
say
expanded,
a
bit.
How
this
is
let's
say
provided
in
the
draft.
E
E
Basically,
the
authors
introduced
a
new
section,
so
they
expanded
section
8,
which
is
about
security,
so
they
believe
this
issue
is
being
fixed
right
now.
Next,
like
this,
and
finally,
there
was
also
discussed
by
roman,
about,
let's
say,
security
at
the
beginning.
The
draft
was
not
including,
let's
say,
all
the
possible
mechanisms
to
deal
with
the
typical
security
issues.
E
In
let's
say
talking
with
the
authors,
they
explained
me
that
actually
they
tried
to
expand
the
base
text.
So
again
they
touched
the
section
eight
of
the
draft
and
also
they
pointed
out
that
speaking
of
security
is
probably
a
much
broader
subject
than
just
the
dealing
with
the
typical
security
aspects
in
a
plc
network.
E
So
just
at
player
two,
so
their
idea
was
to
say,
expand
the
set
of
security
mechanisms
not
just
dealing
with
layer
2,
for
example,
payload,
encryption
or,
let's
say
cross
authentication
from
a
device
to
the
pan
coordinator,
but
at
the
other
mechanisms
at
every
possible
layer
of
the
stack,
including
the
application
layer.
So
basically
they
introduced
a
comment
that
you
see
here
in
the
slide
additional
end-to-end
security
services
that
are
probably
active
at
every
possible
layer,
and
they
explain
me
that
that
is.
E
This
is
also
let's
say,
related
to
the
user
you
make
of
the
plc
network
and
of
the
applications
that
actually
the
network
is
used
for,
so
that
we
can
move
to
the
final
slide.
E
They
wanted
to
ask
further
feedback
to
the
chairs,
whether
it's
possible
to
move
on
removing
the
discus
and
clearly
having
the
possibility
of
developing
probably
a
couple
of
new
versions
just
to
address
the
remaining
comments
before
entering
the
publication
queue,
and
I
will
say
this
is
it
I
hope
I've
been
clear
enough
in
any
case,
if
there
are
questions
you
can
ask
me
or
clearly
send
to
the
mailing
list.
Thank
you.
C
Well,
perhaps
perhaps
just
the
point
that
eric
mentioned
that
the
authors
may
want
to
consider
the
comments
in
the
last
email
from
benjamin
and
then
probably
the
document
can
proceed
further.
C
F
Multicast
is
fine,
yes,
let's
take
them
in
order,
but
I
just
want
to
to
make
sure
that
we
have
enough
time
for
the
last
one,
so
I'll
be
quick
on
on
most
of
them
just
to
make
sure
we
have
enough
time
on
a
prefix
advertisement.
Basically,
because
that's
where
I
would
like
to
see
discussions
so
yes,
marticus,
please.
F
I
I'm
seeing
it
yes
very
nice,
many
thanks,
michael
so
so
this
first
line
of
introduction
fits
for
pretty
much
the
full
presentation.
I'm
gonna
do
so
just
giving
some
history
on
the
work
we've
done
in
this
group
on
what
we
call
six
lopez
neighbor
discovery,
but
we'll
see
that
has
grown
a
lot
beyond
six
low
pound.
But
still
we
are.
F
We
are
the
source
of
of
this
work,
and
today
I
will
be
talking
about
what
what
what
we
call
unicast
lookup,
which
is
basically
converging
a
backbone
network
for
both
traditional
neighbor
discovery
and
the
the
state
for
address
the
configuration
from
six
open,
nd
and
sharing
a
six
lbr,
basically
to
do
unicast
lookups.
So
that's
one
draft
we'll
talk
about
today
and
and
what
I'm
talking
about
now
is
the
multi-gas
registration,
so
extending
basically,
six
lap
and
nd
address
registration
options
for
any
cast
and
multicast.
F
So
since
last
atf
we've
pumped
a
document
version
twice,
one
change
was
minor
in
terms
of
edition,
but
it
was
important
in
the
field
is
there
was
no
discussion
at
all
about
all
nodes,
multicast
learning,
scope,
multicast
group
and
effectively
in
ipv6.
Every
host
is
implicitly
in
that
group,
so
just
added
some
text
to
say
well.
This
is
true
too
so
if,
if
the
cxlr
sees
any
traffic
from
a
host
registration
from
a
host,
so
it
has
the
estilio
of
that
also,
basically,
implicitly,
that
host
is
a
target.
F
If
there
is
an
ffo2
column
column,
one
packet,
we
have
refined
how
this
address
protection.
Rfc
8928
is
leveraged
for
registering
address.
So
we
have
more
text
on
that
and
that's
another
draft
I'll
be
talking
about
today,
but
we
are
proposing
a
method
to
register
ipv6
addresses
to
best
so
to
bgp,
basically
in
the
evpn
environment,
so
using
using
it
545
as
the
registration
protocol
to
be
redistributed
into
into
a
vpn
and
basically
we
would
like
to
be
able
to
to
register
not
only
unicast
but
also
anycast
and
multicast.
F
So
there's
some
text
about
that
since
atf-112.
I'm
sorry
during
atf
112,
we've
discussed
any
cast
and
backward
compatibility,
so
so
that
was
published
right
during
the
atf
session,
and
maybe
people
have
not
seen
it.
So
I
just
want
to
insist
that
that
was
done
and
there
was
the
the
we
needed
a
flag
field
in
theater
and
we
did
not
have
one
so
we
we
repurposed
the
status
of
the
request.
F
You
know
the
status
only
valid
in
the
response,
and
so
we
we
repurposed
the
status
field,
which
was
basically
reserved
on
on
the
head
message
to
carry
the
flags
and
now
we
can
carry
the
d-dart
is
for
any
caster
multicast
address.
So
these
are
the
recent
changes
since
so
on
any
question
at
this
stage
just
interrupt
me.
F
F
I'm
not
saying
we
necessarily
call
or
what
but
role
is
not
yet
really
observing
this
document,
but
it's
the
the
main
change
that
we
do
here
is
not
read
the
you
know
the
a
and
m
bits
in
the
registration
to
say
any
guest
or
multicast.
What's
really
important
is
how
we
change
the
basically,
the
ripple,
underwear
leaf
work,
which
is
rsc
9010
to
expose
those
anycast
and
multicast
addresses
in
ripple
yield.
F
F
So
if
you
guys
could
comment
on
the
list
and-
and
you
know
basically
express
comments
like
see
it
as
an
only
one
good
place-
call
from
this
group
if
you
like,
but
it's
mostly
passing
the
token
on
this
afternoon,
we'll
be
talking
about
the
patrol
as
well.
C
C
F
You,
if
you
remember
this
work
was
tiered
actually
by
the
way,
son
association.
I
mean
that's
why
sun
is,
is
a
group
that
standardizes
technology
for
the
smart
grid
based
on
repo
and
six
japan,
and
I
also
asked
them
to
publish
a
review
on
this
list.
F
F
F
Actually,
no,
and
that
would
be
a
good
thing
to
discuss.
Actually
I
I
I
I
I
remember
very
well
the
constraint
cast
it's
just
that
well
that
it
existed
and
so,
but
but
no
I've,
not
I'm
not
dug
into
that.
Do
you
want
to?
We
can
work
offline
on
that.
If
you're
interested
yeah,
we
probably
should
yeah
we're
welcome
so
any
cast
a
unicast
lookup.
F
F
So
then,
again
same
family,
some
introduction,
so
basically
with
rfc8929,
we
we've
got
what
we
call
the
background
router,
which
is
approximately
function,
so
you
can
register
on
the
lln
on
the
6lowpan
network.
Two
addresses
and
the
6br
will
do
nd
proxy
for
you
on
the
backbone,
and
that
applies
to
classical
154.
That
applies
to
that
11.
That
applies
to
many
things,
but
at
the
moment
there
was
no
real
work
on
what
happens
if
we
want
to
to
use
the
registration
on
the
backbone
side
as
well.
F
F
Now,
if
you
have
a
6lbr
on
the
backbone,
that
kind
of
tells
you
that
you
can
use
it
not
only
as
a
dad
database,
but
also
for
lookup,
and
so
what
this
this.
So
so
you
avoid
the
broadcast
or
the
bump
as
they
call
it.
You
know
broadcast
unknown
and
multicast
flows
on
the
backbone.
If
you
can.
First,
ask
the
six
lbr:
oh
by
the
way,
do
you
have
a
registration
for
this
address,
in
which
case
I
won't
do
the
classical
lookup
of
that.
F
So
that's,
basically
what
this
document
says.
It
proposes
a
way
to
place
the
6lbr
on
the
backbone
and
remember
the
6lbr
is
very,
very
abstract.
I'll,
come
back
to
that
on
the
evpn
discussion,
but
the
the
extracts
6lbr
is
now
reachable
for
the
backbone
or
even
far,
far
away
on
the
internet,
because
it's
a
global
ip
address
and
we
can
effectively
pour
it's
it's
database
information
not
only
for
oh
is
this
address
duplicate,
but
also,
what's
the
address
resolution.
F
So
do
we
care
about
publishing
this
work,
which
basically
says
now
you
can
have
six
lupine
devices
on
the
backbone,
sleeping,
etc,
because
now
you
can
benefit
from
the
proxy
for
sleep
proxy
et
cetera,
or
do
we
want
to
keep
six
le
pen
at
the
edge
on
the
other
side
of
the
backbone
and
outside
of
the
background
personally
noah,
you
know
my
side.
I
want
basically
to
converse
the
registration
on
the
backbone,
but.
F
G
F
Yeah
I
mean
if
everybody,
basically,
the
more
devices
contribute
to
the
registration
on
the
backbone.
The
last
bump
traffic
broadcast
unknown
multicast.
You
will
get
on
the
backbone,
because
the
draft
will
be
more
and
more
useful
because
the
nodes
will
be
able
to
to
look
up
through
the
6lvr
and
never
again
do
a
multicast.
F
Is
the
evolution
of
efficient
nd
I
mean,
or
it's
all
intel
efficiently
was
always
completely
linked
to
this,
but
we
did
not.
I
don't
think
we
really
discussed
of
placing
the
6
lbr
on
the
backbone
and
doing
any
cast
lookup.
No,
no,
we
do,
but
it
was.
It
was
the
obvious
continuation
of
efficient
individuality
yeah.
So
we
certainly.
G
F
Yeah
and
we
actually
started
this
document
at
six
man
and
six
man
for
anything,
you
know
related
to
six
lap
and
nd
I
mean,
doesn't
really
care,
and
so
I
presented
it
once
or
twice
raised
a
few
eyebrows
and
and
that
was
it
pretty
much
like
efficient
nd.
I
mean
you've
seen
the
lack
of
interest
to
progress.
This
work
at
six
men,
six
man
is
more
maintenance.
As
I
see
it,
and
so
look
at
the
service
six
right.
F
They
do
the
work
in
spring
and
sometime
they
when
they
they
have
something
then
to
just
get
six
men
to
validate
that.
It's
okay
or
changes
change
a
little
bit,
but
here
same
thing:
we've
done
this
work
and
six
men
will
basically
just
say
it's
okay
or
not,
but
it's
it's.
It
won't
advance
in
six
months.
They
are
not
doing
that
sort
of
thing.
F
F
If
you
look
at
8929,
which
is
the
background
router,
the
global
six
lbr
is
effectively
the
collection
of
all
the
and
the
information
on
all
the
six
lbr,
the
6bbrs,
because
all
the
backbone
routers
they
they
have
a
partial
view
of
the
the
6lbr
for
their
own
local
llm.
F
But
the
real
6lbr
is
the
aggregation
of
all
those
views
and
the
way
this
real
6lbr
distributed
to
6bbr,
I'm
sorry
is
red,
is
by
doing
classical
ending
for
the
backbone
or
over
the
proxy
function.
So
it's
not
a
centralized
box
at
all.
It's
really
the
collection
of
all
the
background,
routers
together
being
read
through
nd.
That's
what
the
macbook
router
does
now.
Can
we
move
to
the
next
slide
where
the
evpn
one?
F
Let
me
show
you
another
way
of
deploying
s6
lbr
and
in
this
case
6lbr
would
be
literally
bgp.
The
all
pgp
network
that
serves
the
vpn.
A
F
Michael,
yes,
I
see
them
so
please
bear
with
me
because
this
slide-
where
was
not
done
for
this
audience,
and
just
I'm
just
telling
you
that
I
presented
it
to
them
the
classical
evpn
world
and
the
classical
cloud
world
is
really
really
ipv4.
They
they
understand.
F
People
understand
ipv6,
but
not
in
the
same
depth
as
people
doing
iot,
for
instance,
right
and
and
so
sometimes,
and
really
in
enterprise
networks.
They
mostly
don't
let
slack
at
all
and
they
work
with
the
hcp
v6.
Just
the
same
way
they
work
with
v4.
So
it's
kind
of
easy
to
forget
that
there
is
more
to
ipv6
than
dhcp
for
the
best
for
the
better
and
the
worse
right.
So
so,
basically
I
I
was
with
this
slide.
F
I
was
making
the
point
that
as
long
as
you,
you
use
the
hcp
you've
got
this
round
trip
between
the
client
and
the
server
that
you
can
observe
on
the
way.
So
you
can
snoop
the
hcp
reliably.
You
can
expect
it
one
address
per
host
or
per
interface.
You
know
it's
going
to
come
actually
in
our
access
points
find
that
machine.
F
You
don't
know
for
sure
when
the
host
forms
an
address
when
it
stops
using
it.
There
is
absolutely
no
signal
that
this
host
will
stop
using
this
address,
and
so
you
end
up
with
addresses
that
you
don't
know,
exist
and
addresses
that
are
no
more
used,
but
you
still
maintain
a
state
in
the
network.
For
them,
slack
was
not
at
all
defined
for
maintaining
state
in
the
network.
It
was
meant
for
maintaining
caches
in
the
network.
F
It's
very
very
different
because
evpn
needs
a
deterministic
state
that
can
be
injected
in
bgp,
so
using
slack,
addresses
and
redistributing
them,
snooping
them
and
redistributing
them
in
evpn
needs
to
broadcast
unknown
and
multicast
traffic,
which
is
one
thing
they
want
to
avoid.
So
this
next
slide
basically
explains
the
kind
of
crimes
we
have
with
slack
when
we
want
to
interwork
with
evpn,
it
summarizes
what
they
just
said.
F
She
wants
to
maintain
this
slide,
but
I
don't
have
so
much
time
so
so
that
was
that
was
true
with
slack
until
until
we
made
ipv6
and
d
state
four
and
that's
eight
five,
four
five,
seven
sixty
seven,
seventy
five
and
five,
four
five
and
nine.
I
mean
the
whole
series
that
I
have
shown
on
the
first
slide.
F
With
this
protocol
we
effectively
synchronize
the
state
about
the
address
between
the
host
and
the
network.
Now
we
have
a
deterministic
state
that
we
can
redistribute
into
routing
and
effectively.
8545
carries
address,
control
semantics,
which
help
this
redistribution.
In
particular,
we
negotiate
the
lifetime
and
that's
generated
from
67.75,
and
we
we
have
special
signaling
to
say.
Please
redistribute
my
address,
so
the
router
can
inject
the
address
in
a
proxy.
That's
at
nine
to
nine
in
ripple.
That's
nine,
zero,
ten,
zero!
F
Ten
at
ninety
ten-
and
in
this,
in
this
case,
for
dvpn
and
here
in
the
cake,
we
have
a
quite
simple
address
protection
mechanism
which,
with
eight
nine
two
eight,
so
we
can
do
savvy
and
all
those
games
we
can
bar
traffic,
which
is
not
sourced
by
the
user,
who
effectively
registered
that
address
on
the
first
stop
switch
or
first
operator.
F
So
basically
it
is
the
the
draft
that
I
presented
to
bess
and
I'm
trying
to
get
it
adapted
is
explain
how
you
will
redistribute
rfc8505
and
928
in
evpn,
and
if
you
look
at
it
that
effectively
makes
the
bgp
tables
that
are
synchronized
in
every
every
node
v6
lbr,
because
if
vpn
basically
advertises
routes,
type
2,
which
really
are
combination
of
ip
and
mac
and
type
5,
which
will
be
the
ip
and
and
what
we
do
is
we.
F
We
extend
the
support
that
was
already
there
for
basically
and
the
ip690
there
was.
There
was
a
beginning
lpv6nd
in
there.
There
is
no
c
for
that,
and
so
we
extend
that
signaling
and-
and
we
also
we-
we
effectively
have
two
different
fields
that
we
update,
because
we
need
a
number
of
flags
and,
and
we
need
to
expose
the
lifetime,
we
need
to
expose
the
rover.
So
how
we
do
that
is
is
explained
in
this
document.
F
The
bottom
line
is
now
we
can
provide
a
secured
address
and
that's
why
you
have
secured
the
titles,
because
eight,
nine,
two
eight
to
nine
and
eight
nine
to
eight
information
is
effectively
injected
in
bgp
and
so
bgp
can
can
block
a
host
which
would
like
to
steal
on
the
trust
to
impersonate
over
a
vpn.
F
C
A
question
well,
eric
is,
in
the
queue
sorry.
H
So
so,
when
people
do
this
with
ipv4,
presumably
they
can
know
when
addresses,
are
no
longer
being
used.
The
unregistered
part
right
by
setting
a
lease
at
an
hour
or
24
hours
or
whatever.
F
H
H
F
We
we
have
a
lifetime
in
the
registration
and,
what's
neat
with
6
75
is:
is
the
host
proposes
a
lifetime
and
the
router
confirms
that
or
modifies
that
like
reduces
it,
so
we
we
can
effectively,
we
register
with
a
lifetime.
Yes,
we
do
now.
The
resolution
is
whatever
we
can
signal.
I
don't
remember
exactly
it's
two
bytes.
I
I
don't
know
about
the
unit.
It's
probably
seconds.
F
Well,
you
have
both
right,
you
can
normally
the
the
draft
should.
If
you
stop
using
address,
there
is
a
shirt.
You
know
something
like
register
it
with
a
lifetime
zero,
which
means
unregister.
I
F
The
other
thing
is
there
is
there
is
text
which
says
that
your
registration
should
map
your
intention
with
this
address
like
if
you
are,
if
you
have
the
intention
to
use
it
long
term
use
a
long
lifetime.
If
you
have,
if
you
use
it
like
just
a
very
temporary
address,
use
a
short
lifetime.
Now
it's
under
the
appreciation
of
the
stack
to
decide
what
kind
of
lifetime
it
will
ask,
so
we
have
a
lot
more
control
actually.
F
C
In
theory,
according
to
the
agenda,
that
would
be
like
16
minutes,
although
we
also
have
additional
time
since
we
have
like
20
minutes
of
flex
time
for
the
whole
session.
Okay,
that's
neat.
F
Okay,
so
same
first
slide,
you
know
the
the
big
family
that
this
group
has
developed.
So
so
I
I
you
know,
I've
been
working
on
on
cloud
usage
of
of
what
we
did
in
this
group.
F
Don't
be
too
surprised
with
the
vpn,
but
the
next
thing
that
happens
in
cloud
environment-
and
you
will
realize
it
happens
in
iot
environments
as
well,
is
at
some
point.
You
want
to
give
this
device
not
just
a
an
address,
but
you
want
to
give
it
a
prefix
and,
and
the
kind
of
usage
is
in
the
cloud.
F
It's
you've
got
a
virtual
router
in
your
host
system
in
your
in
your
server
like
something
like
calico
and
and
basically
you
want
the
devops
to
be
able
to
manage,
not
only
addresses
but
prefixes,
and
so
the
devops
would
would
configure
prefixes
on
their
systems.
And
what
you
want
is
the
system
to
advertise
that
to
whatever
routine
you
have
in
the
cloud
in
a
fashion,
that's
completely
agnostic
to
the
routing
in
the
cloud.
So
you
can
do
your
rift.
You
can
do
bgp
you
can
do
whatever
and
for
addresses.
F
F
Now
redistributing
is
not
something
new
at
all.
We
we
do
it
with
a
repo
with
the
ripple
of
nowhere
work.
In
this
case
the
6lm
registers,
no
trust
with
the
arbitrate
and
the
the
ripple
first
stop
ripple
aware:
router
will
effectively
react
to
the
air
flag
and
injected
ripple.
F
The
same
flag
is
used
in
eight
nine,
two,
two,
eight
two,
nine,
I'm
sorry
by
the
bible,
router
to
to
decide
whether
or
not
to
proxy
and
that
flag
is,
is
also
leveraged
in
the
best
work.
F
So
what
we
are
looking
at
is
not
something
new
redistribution,
but
reducing
prefixes
are
supposed
to
host,
and
this
is
a
quick,
quick
view
on
how
how
that
happens.
So
this
is
the
traditional
ripple
non-storing
mode,
so
each
node
will
have
an
address
in
the
same
prefix
and
basically,
the
nodes
send
a
non-storing
model
like
this
red
packet,
the
root
and
and
the
root
can
construct
the
source
rod
path
back,
which
is
the
ac
via
a
b
which
is
connected
now
with
the
ripple
and
where
leaf.
F
What
you
do
is
you've
got
this
host,
which
which
for
which
we'll
see
an
array
from
c
from
router
c,
auto
conf,
address
a
column,
column,
l
for
power
node,
and
basically
it
will
be
the
node
c
that
will
advertise
l
as
a
non-storing
now
on
the
alpha.
So
what
happens
between
a
column,
column,
l
and
a
column?
Column
c
is
purely
five.
F
Four
five
l
is
completely
agnostic
and
aware
that
it's
repo
and
the
address
is
injecting
the
writing
and,
and
the
note
can
be
served
so
so
the
question
again
is
yeah.
We
can
do
that
for
addresses,
but
what
about
prefixes
I
mean?
Does
that
make
any
sense,
and
actually
there
are
a
number
of
use
cases
where
it
does
make
sense,
and
the
broad
category
is
a
stub
network.
It's
a
network:
this
is
either
inside
the
node.
F
What
we
call
a
networking,
node
or
a
recursive
networking,
but
there
is
a
node-
is
a
network
for
the
next
level
of
recursion
or
a
private
network,
a
virtual
network
that
would
be
bandaged,
for
instance,
by
communities
or
something
you
could
also
have
a
net
function
and
a
private
real.
That's
really
what
you
would
do
in
communities,
but
you
can
also
connect
through
reaper
or
any
network,
a
smaller
network
of
private
iot
devices,
without
really
knowing
what
kind
of
routing
takes
place
there.
F
What
you
want
is
is
just
be
able
to
signal
through
the
same
simple
registration.
We
have
with
h505
hey
this
device,
which
does
something
different
from
ripple
effectively
owns
this,
this
private
room
or
something.
F
F
This
is
a
typical
structure
that
triple
could
build,
so
each
node
abcd
get
a
prefix
abcd
and
if
c
connects
to
b,
then
it
will
form
a
prefix,
an
address
of
this
prefix
and
then
you
can
expose
the
the
same
sequence
of
source
route
information
again
and
and
it's
gonna
work,
fine,
because
in
repo,
what
what
b
will
expose
is
b
column
column,
flash
64.
F
F
Now,
if
we
wanted
to
do
the
exact
same
thing
for
a
ripple
unaware
writers,
now
we
don't
have
it,
we
we
don't
have
a
way
to
for
not
l
to
effectively
say:
oh
everything
in
the
alcohol
I'm
constantly
64
is
mine,
l
would
have
to
talk
ripple
and
if
it's
cvpn
l,
we
would
have
to
talk
evpn.
F
F
Please
give
me
the
package,
but
I
don't
know
what
your
routing
protocol
is,
and
I
think
was
yesterday
at
six
man,
there
was
a
question
a
use
case
that
was
quite
interesting
where
there
was
a
a
unique
local
prefix,
which
was
that
which
was
owned
by
a
router
which
was
somewhere
on
the
home
network.
F
If
that
guy
had
used
this
registration
to
talk
to
the
home
gateway
problem
guard
packets
would
reach
the
home
gateway.
Com
gateway
would
find
the
registration
for
the
una
prefix
route
end
of
the
story,
but
we
we.
We
don't
have
this
simple,
nd
extension
now
remember.
Jen
at
some
point
talked
to
the
group
and
say
hey:
we
are
not
listening
to
arrays.
This
ula
router
would
have
advertised
arrays,
but
then
the
home
gateway
does
not
listen
to
arrays,
so
we
lose
the
information.
That's
why
we
have
the
problem.
F
Well,
in
this
case,
we
use
rs
effectively
to
register.
So
it's
just
like
ns
for
for
host
that
naturally
would
migrate
it
to
rs.
I
guess,
but
that's
the
group
to
decide
in
this
case
effectively.
The
home
gateway
would
listen
to
the
rs
with
the
address
registration
option
or
something
prefix
registration
option
and
it
will
effectively
know
in
a
fashion
which
is
completely
independent
of
what
routing
takes
place
outside
the
home
network
or
even
within
the
home
network.
F
It
will
know
that
there
is
this
router
which
holds
that
step
and
which
is
connected
and
effectively.
It
still
works.
If
the
step
itself
is
a
different
subnet
on
the
same
multi-step
net
link,
this
is
very
traditional.
Shared
link
existed
since
the
early
times
of
ipv4,
where
you
have
a
same
wire
if
you
like,
where
multiple
subnets
are
deployed,
this
just
happens
that
the
home
gateway
would
pass
the
packet
to
the
router,
which
did
the
registration,
which
would
then
inject
on
the
link.
F
So
yes,
yes,
yes,
we
we,
we
would
register
prefixes
but
hey
when
we
register
addresses.
We
have
this
thing,
which
is
quite
useful,
which
is
that
right
we
want
to
ensure
that
a
given
prefix
is
a
given
address
is
not
a
duplicate,
so
we
would
need
to
do
that
right,
yeah
yeah.
We
would
effectively
mostly
if
we
want
the
devops
to
configure
prefixes
on
their
devices
without
asking
too
much
just
picking
something
in
a
larger
aggregation.
Here
you
have
the
risk
of
duplicate,
or
is
it
free
duplicate?
No,
it's
not.
F
So
basically,
yes,
we
would
need
to
do
that
again,
but
we
would
need
to
consider
not
just
exact
match,
but
also
aggregation
like
some
prefixes
could
be
exposed
as
being
prefixes
from
which
you
can
steal
a
sub
prefix,
and
some
of
those
would
basically
not
be
proposed
that
way.
So
if,
if
you
register,
for
instance,
a
prefix
within
the
prefix-
and
you
have
the
right
to
do
that,
then
you
get
it
if
somebody
wants
to
register
the
same.
F
You
won't
be
able
to
do
it
because
you
own
it
unless
you
say
any
case
something,
but
then
if
somebody
wants
to
dig
into
your
own
prefix,
if
you
did
not
allow
for
that,
you
will
be
rejected
as
well
right.
So
so
you
have
to
consider
aggregation
as
part
of
the
dot,
but
otherwise
yes,
the
very
cool
thing
is,
you
can
do
auto
allocation.
F
F
But
for
me
the
obvious
way
is
to
do
with
rs
what
we
do.
We
did
with
ns
and
do
a
stub
registration
option
now
insist
on
the
factory
stub
right,
because
with
that
we
don't
have
it's
not
a
routing
protocol.
It's
still.
Indeed,
we
are
just
advertising
rich
ability,
but
we
are
not
addressing
cost
etc.
We
are
not
participating
into
the
writing
protocol
very
important
distinction,
and
so
we
just
say
hey.
F
I
have
this
prefix
and
I
want
you
to
to
to
is
yes,
that
is
that
to
inject
it
in
your
own
routing
and
give
me
the
packets
back
please,
and
since
it's
a
tab,
it
won't
be
a
loop.
It
won't
be
anything.
So
that's
why
I
suggested
this
stub
registration
option
name
and
then
in
this
example.
I
have
a
cloud
fabric,
and
I
have
this.
F
This
server
down
below
attached
to
two
leaves
l1
and
l2,
and
it
would
basically
send
the
rs
to
l1
and
l2,
saying
I'm
registering
this
prefix
and
then
I
want
l1
and
l2.
The
two
leaves
could
effectively
inject
it
in
bgp,
evpn
or
rift
or
whatever
else
you
want
to
run
there,
and
the
same
obviously
would
work
for
repo.
C
So
there
is
and
michael
waiting
in
the
queue.
F
Oh
I'm
sorry
I
did
I
had
scrolled
down
and
I
did
not
see
the
queue.
Oh
now
I
scrolled
up,
and
I
see
you
both.
Sorry.
Sorry,
sorry,
it's
my
fault.
It's
just
the
scrolling
thing
I
mean
the
queue
does
not
show
when
you
scroll
down
something
for
me
to
go
guys
if
you
could
make
sure
that
the
queue
shows
outside
of
of
the
list
of
participants
is
always
at
the
top.
That
would
be
very
useful.
I
just
just
made
that
mistake.
Okay,
no
problem
you're.
First.
I
F
We
are
so
abstract
it
fits.
It
fits
as
long
as
you
have,
for
instance,
if
you
have
an
iot
network
instead
of
this
server
down
there,
it's
just
a
a
plain
existing
iot
network,
which
is
v4.
For
instance,
I
mean
a
lot
of
them
are
not
ip
at
all,
but
you
want
to
map
each
device
to
an
ip
address.
Just
map
like
a
net
function
that
would
map
a
mac
to
an
ip.
Then
you
can
expose
effectively
every
device
on
that
slash
p
to
the
ripple
network.
F
So
if
you
see
that's
why
I
picked
on
my
example
before
on
repo
effectively
ripple
has
the
model
already
for
for
lens,
where
each
of
the
routers
owns
a
prefix.
It's
there.
I
mean
it's
always
been
there.
So
this
can
happen
if
the
router
c
is
effectively
the
gateway
to
to
an
ipv6
network
which
which
has
the
prefix
b,
but
it
it
could
also
be
something
else
and
and
that
we
could
not
necessarily.
F
How
can
I
say
this
yeah
it
could
be
anything
it's
there.
What
what
does
not
exist
is
the
capability
to
connect
a
gateway
which
does
not
speak
ripple
so
yeah.
I'm
sorry
for
that,
so
the
use
the
thing
that
exists
today
is
this.
The
thing
that
does
not
exist
today
is
this:
where
you
take
this
iot
gateway,
which
has
a
number
of
devices
below
it
and
which
wants
to
map
the
devices
in
in
that
group
of
devices
to
an
ip7
that
can
be
injected
in
repo,
and
you
don't.
A
F
Yeah,
it's
completely
abstract.
Now
we
we
basically
say
what's
good
with
6lowpan,
what's
good
with
nd,
it's
completely
abstract
writing
protocols,
you
can
you
can
advertise
the
prefix
to
say
hey
reachable,
but
you
cannot
give
a
cost
or
something
like
that:
you're,
not
a
routing
protocol,
but
at
least,
if
you
have
a
stub
you,
you
should
be
able
to
announce
it
and,
like
michael
said,
regardless
of
what
frauding
takes
place
over.
So
I
take
the
example
of
a
cloud
or
I
take
the
example
of
repo.
It
really
doesn't
matter
we're
completely
agnostic.
I
This
is
this:
is
this
enables
6lrs
and
lbrs
to
advertise
prefixes
that
will
be
in
turn
delegated
or
mapped
to
the
constraint
nodes.
F
Yeah
there
is
a
gateway
which
self-transferring
nodes
and
we
want
to
be
completely
agnostic
of
what
it
does.
Maybe
it
does
not
even
do
ip,
but
we
want
to
be
able
to
to
talk
to
every
device
in
there,
so
we
want
to
give
them
each
an
ip
address
and
the
simple
way
for
that
is
that
the
gateway
has
an
ip
address,
all
of
them,
whether
it's
really
the
a
prefix
that
is
distributed
to
the
devices
or
it's
just
mapping
that
that
is
done
at
the
gateway.
F
But
at
least
we
want
to
go
through
the
gateway
to
talk
to
every
modbus
device,
and
for
that
we
want
the
gateway
to
own
the
prefix.
Now
either
the
gateway
speaks
repo
or
we
extended
545
to
say:
hey
the
gateway
is
open
nd,
but
gents
we
can
ex.
You
can
expose
the
stub
as
opposed
to
just
address.
So
what
I
really
want
to
do
is
what
we
did
here
and
made
sense
for
a
single
device.
A
Prefixes
into
ripple
into
the
acp
ripple,
but
that
this
actually
would
be
very
interesting,
because
it
would
mean
that
in,
for
instance,
the
the
knock
which
might
not,
which
might
run
the
acp
as
a
native
network,
rather
than
a
overlay
that
that
would
actually
permit
us
to
have
some
structure
in
the
knock.
I
think
that
would
be
very
valuable
and
you
know
I
think
that
would
be
a
so.
I
think
this
is
a
kind
of
a
useful,
very
useful
thing
to
anima
this.
A
This
extended
prefix
allocation,
and
I
just
wanted
to
say
actually
in
response
to
schwester's
question
to
you
about
charter.
It
might
very
well
be
that
this
work
does
not
belong
with
six
low,
but
this
is
essentially.
I
think
that
we
need
to
be
aware
of
this,
because
this
is
essentially
an
evolution
of
8505,
which
is
our
document
in
other
other
working
groups.
Right.
A
So
I
think
that's
a
relevance
to
to
this
working
group
is
that
our
we
wish
to
have
our
our
children
go
forth
and
be
fruitful
right.
F
A
F
F
So
yes,
my
argument
is,
is
effectively
this
l
node
could
be
an
iot
gateway.
We
have
many
many
cases
of
gateway
in
industrial
and
where
you
have
all
sorts
of
industrial
protocols,
I
think
they're
on
the
dressing
scheme
and
basically,
what
we'd
like
is
to
be
able
to
have
the
gateway
map
every
address
in
its
network
to
ipv6
and
then
inject
that
in
the
routing,
regardless
of
what
protocol
runs
in
the
router.
F
C
G
D
F
So
in
this
case
there
is
absolutely
no
relation
between
a
and
b
it
could
be
two
different
cars
served
by
two
different
service
providers.
It's
just
and
then
you
build
the
money
of
cars
and
that
still
works.
F
So
no
there
is
no
ex
no
relation
there
can
be
other
can
be
not
right.
You
don't
really
care,
it's
just
that
when
the
car
say
hey
the
car
and
you
have
an
iot
network
inside
that
car,
all
the
the
the
the
units
that
you
can
find
in
the
car
that
is
served
through
wi-fi,
then
the
car,
as
basically
is
exposing
alcohol
and
column
a
column,
column
64
right.
F
F
Just
for
visitors
and
b
should
use
a
suffix
b
in
this
case
for
a
column,
column
b,
which
also
would
be
anonymous,
but
the
bottom
line
is,
you
can
effectively
have
b
connect
to
a
by
forming
the
transmitter
based
on
a
arrays
and
recursively.
You
do
that
and
you
do
report
between
them
and
guess
what
you
form
a
network
that
reaches
the
outside
of
a
parking
lot
or
connects
mna
together.
F
F
F
Okay,
so
nothing
much
more
just
this
is
slightly
made
for
the
evpn
people,
but
basically
you
see
you
would
see
how
it
could
happen
in
in
the
vpn
case,
but
yeah.
Then
again,
it's
completely
agnostic
to
the
writing
protocol
that
you
would
run
if
we
get
a
little
bit
gorier
on
what
we'd
like.
F
So
the
main
change
is
to
to
advertise
tabs
stop
prefixes
are
supposed
to
host.
You
can
effectively
advertise
slash
96.
If
you
want
to
to
expose
a
private
ipv4,
a
domain
like
you
would
do
for
for
communities,
you
can
you
can
you
we
could
if
we
work
on
this
draft,
add
more
information
about
policies
and
echoes.
So
if
you
want
to
have
access
countries
etc,
they
have
the
right
to
do
this.
I
claim
the
right
to
do
that
for
this
prefix.
Then
then
that
could
be
signaled.
F
There
is
a
lot
of
load
balancing
taking
place.
It's
not
right.
It's
just
load
balancing
and
the
question
is:
if
I
have
multiple
of
those
gateways
serving
the
same
network,
it
might
be
that
you
want
the
weight
to
be
unevenly
distributed
between
those
guys,
and
so
you
could
effectively
advertise
information
about
that
and
then
all
sorts
of
things
which
could
be
placed
for
v4
like
like
donut
id
vrf,
etc.
F
F
And
so
basically,
that's
what
I'm
looking
for
is
is
a
discussion
on
this
list,
and
I
have
I
had
the
point
by
shweta
is
that's
this
fit
charter?
I
think
it
does.
It's
certainly
not
limited
to
iot,
but
before
I
start
going
into
a
draft,
as
you
know,
it's
the
draft.
Zero
is
always
a
lot
of
work.
If
you
want
to
do
it
right,
I
wanted
to
expose
the
dangers
to
the
group
and
and
kind
of
get
a
go.
No
go
feedback.
J
Yes,
I'm
here
you
hear
me
so
actually,
if
you
can
go
back
one
slide
just
once
like
so
I
I
think
that
the
work
is
interesting.
I
just
wanted
to
make
a
comment
on
the
third
metal
main
bullet,
adding
metrics
to
influence
load
balancing.
Yesterday
it
was
the
there
was
this
kind
of
compute
and
networking.
J
F
Yes,
exactly
that
could
be
exactly
very,
very
good.
That's
exactly
what
the
sort
of
thing
we
have
in
mind
yeah,
if,
if,
basically,
if,
for
instance,
if,
if
you
have
kubernetes
again
right
and
you
can
decide
how
many
pods
you
have
on
different
servers,
you
could
basically
load
balance
on
the
number
of
pods.
I
G
F
F
So
you're
talking
about
the
sixth
lbr
right,
sabr,
the
6mbr,
the
registry,
the
registry
is,
is
only
useful
if
you
do
the
the
function
that
is
equivalent
to
that
right.
If
you
want
to
auto
configure
the
addresses,
so
basically
say
those
are
cars
and
they
have
service
providers
and
service
providers
did
give
them
a
slash
64,
which
is
a
b
or
c.
Now
those
cars
end
up
in
the
same
parking
lot
and
they
want
to
to
form
a
melee
of
sort
with
ripple.
F
F
If
you
really
want
to
ensure
that
the
ua
prefix
that
is
autocad
for
anonymity
purpose
just
for
forming
this
network
is
really
unique
inside
the
parking
lot,
then
you
would
have
a
6lbr
if
you're
using
global
addresses,
you
would
not
need
the
6
apr,
because
the
very
interest
is
every
prefix
abc
is
unique,
it's
being
just
given
by
the
each
service
provider
and
that,
yes,
there
is
no
no
relationship
at
all
between
a
b
and
c.
G
F
F
The
only
one
that
has
anything
to
do
is
not
be
itself
because
he's
as
a
host
on
one
antenna,
if
you
like,
is
he's
a
host
to
a
and
then
as
a
router
is
the
writer
for
prefix
b.
So
the
interconnection
between
a
and
b
is
the
fact
that
there
is
a
router
b
which
acted
as
a
host
on
one
leg,
to
form
an
address
from
a
and
on
the
other
leg,
as
acts
as
a
router
for
exposing
b.
It
creates
that
link
that
connection.
F
If
you
like,
during
the
time
where
it's
it's
reachable
from
from
a
and
when
b,
goes
away
from
a
address,
a
column,
column
b
will
will
go
away.
It
will
have
to
deprecate.
F
Without
triple
they
can't,
but
once
you
run
ripple
and
say
a
becomes
the
root
just
because
from
the
diagram
it
looks
like
obvious,
then,
if,
if
a
node
in
a
pings
an
address
like
b
column,
column
c
through
ripple,
it
will
know
it's
there.
That's
that's!
When
you
need
the
routing
right,
I
mean
the
routing
ripple.
Does
exactly
what
I've
shown
on
the
slides.
F
Basically
ripple
builds
this
right.
A
is
the
root
blah
blah
here
is
routing
tables
in
every
node,
so,
for
instance,
in
node
b,
which
is
in
the
middle
prefix
b
appears
as
connected
right
and
it's
actually
owned
and
a
prefix
a
is
connected,
but
as
a
host
and
then
b
has
a
default
route
via
a
which
is
the
root
and
and
c
and
d.
They
basically
auto
confident
trust
from
from
b.
So
they
they
see
b
us
connected.
F
F
G
F
G
Yeah,
okay,
I
I'm
looking
forward
to
your
draft
because
to
me
this
makes
absolutely
nothing.
F
This
would
not
be
in
the
draft.
I
mean
this
this.
This
has
been
my
ripple
course
for
15
years,
but
it's
not
it's
not
in
in
in
the
draft,
because
the
draft
would
more
well
would
would
probably
discuss
that
flight
well,
which
would
probably
curving
the
other
one
yeah.
If
you
like,
I
mean
to
explain
this
background
that
we,
I
don't
want
to
overload
the
document
either
with
ripple
consideration
when
it's
really
talking
about
md,
so
yeah
I
mean
I
would
be
happy
to
discuss
about
those
slides
anywhere
in
any
form.
G
This
is
pure
deployment,
it's
not
so
interesting.
How
ripple
does
this
it's
more
interesting?
What
capabilities
and
responsibilities
you
just
assigned
to
the
various
nodes
in
the
network
here.
F
Oh
yeah
cool
cool
cool,
so
now
we
are
back
to
to
this
case.
It's
basically
saying
there
is.
There
is
a
rotted
network
where,
where
c
is
a
6lr,
if
you
like,
and
then
there
is
this
gateway
which
needs
a
prefix
and
doesn't
speak
repo,
so
it's
a
ripple,
underwear
router
and
we
call
that
an
external
destination
in
our
c89.
F
C
Okay,
so
sorry
to
interrupt,
there's
also
one
paying
in
the
queue.
So
perhaps
we
may
have
like
time
for
an
extra
question
by
one.
I
K
Okay,
thank
you.
Hi
pascal
does.
K
Does
this,
and
does
this
mean
the
root
is
gathered
by
the
by
the
root
node
and
then
for
the
communication?
Every
packet
will
carry
the
root
message
in
the
encapsulation.
F
Oh,
if
you're
using
in
this
case
it's
using
non-storing
mode
and
so
rca9008
applies,
and
yes,
it
does
mean
that
c
will
encapsulate
the
packet
to
the
root.
F
Oh,
I
think,
if
I
remember
well,
you
know
we
had
a
lot
of
trouble.
Writing
nine
zero,
zero
eight,
but
this
is
this-
is
whether
it's
it's
really
a
ripple
and
overleaf
or
it's
an
excellent
destination,
doesn't
make
a
difference,
and
my
memory
is
effectively
c
will
encapsulate
to
the
root
and
then
the
root
will
either
encapsulate.
If
it's
another
rural
destination
or
if
it's
not
a
real
destination,
then
he
might
no
well
sorry
if
it's
non-storing
mode,
it
will
encapsulate.
F
So
yes,
okay,
I
understand
okay,
thank
you.
But
yes,
always
you
know
go
back
to
nine
zero,
zero.
Eight!
It
was
so
hard.
We
always
miss
things
when
we
do
it
by
memory,
but
same
as
a
rule,
I
mean
whether
it's
a
mixtal
host
or
external
prefix
doesn't
make
any
difference.
C
Okay,
so
thanks
for
the
presentation
and
discussion,
so
it
appears
that
well,
it
may
be
good
to
confirm
further
on
the
mailing
list
that
there
is
interest
in
this
work.
Also,
it
was
good
to
clarify
relationship
with
the
charter,
so
it
appears
this
whole
work
area
is,
can
apply
in
iot
networks,
but
also
it's
not
limited
to
that
so
yeah.
It
was
also
useful
to
clarify
those
aspects
as
well.
C
L
C
C
So,
as
the
working
group
knows
well,
rfc6282
has
been
the
basis
for
header
compression
in
6v,
pan
and
also
in
six
low.
It
was
designed
for
15.4
as
the
target
technology
to
support
ipv6
on
and
it
has
been
adapted
or
reused
for
several
relatively
similar
iot
technologies
several
times,
such
as
the
ones
that
we
are
handling
in
six
load
and
with
this
rfc
it
is
possible
to
compress
an
ipv6
gdp
header,
typically
48,
bytes
down
to
a
size
of
seven
bytes
in
the
best
case
with
global
addresses.
C
But
then
we
also
have
the
recent
publication
of
rfc
8724,
also
known
as
chic,
which
is
a
product
of
the
lp1
working
group.
She
defines
adaptation
layer,
functionality
comprising
header,
compression
and
fragmentation,
and
it
has
been
designed
for
technologies
which
are
even
more
constrained
in
terms
of
communication
capabilities
than
those
which
we
deal
with
in
six
volt.
Pan
or
six
load
such
as,
for
example,
lp1
technologies.
C
C
If
we
assume
a
header
without
options,
then
with
six
load,
pan
the
resulting
size
of
ipv6
udp,
coop
header
would
be
11
bytes
in
total.
If
we
consider
the
options
in
a
co-op
header
such
as
those
in
table
6
of
fc8824,
the
resulting
size
would
be
23
bytes.
C
C
As
you
will
see
later,
it
is
possible
to
achieve
a
theoretical
improvement
by
a
factor
which
might
be
even
greater
than
two,
even
if
we
include
a
third
byte
as
a
sheet
dispatch
and,
however,
the
disclaimer
here
is
that
actual
improvement
in
practice
will
be
lower
depending
on
various
parameters
and
features
such
as
the
device
hardware
and,
in
particular,
the
sleep.
Current
consumption
also
mac
layer,
settings
application,
layer,
settings
including
the
payload
size
network,
topology,
and
so
on.
C
So
just
to
give
a
few
more
details
on
this
here.
This
figure
shows
on
the
vertical
axis,
which
is
the
maximum
theoretical
battery
lifetime
improvement.
Factor
that
can
be
achieved
for
the
cases
considered
as
a
function
of
the
payload
size,
which
is
the
horizontal
axis
here.
We
assume
short
mac
addresses
intrapan
communication
and
again
a
battery
operated
device
which
transmits
packets
periodically.
C
So
here
you
can
see,
there
are
red,
curves
and
blue
curves.
The
red
ones
correspond
to
a
star
topology
scenario,
and
the
blue
ones
correspond
to
a
multi-hop
scenario
with
mesh
under.
I
will
refer
to
route
over
later
in
the
presentation
and,
as
you
can
see,
while
the
improvement
decreases
with
quad
payload
size.
Of
course,
it
is
still
possible
to
achieve
quite
significant
improvement,
at
least
theoretically
with
shorter
payload
sizes.
C
C
Here
you
can
see
the
format
on
the
slide,
which
starts
on
the
left
with
the
sheet
dispatch
which
signals
that
what
comes
next
is
a
packet
with
a
header
which
has
been
compressed
by
using
chick
and
the
chic
header,
the
compressive
header,
compresses,
two
components,
a
rule
id
and
if
any,
a
compression
residue.
So,
in
the
previous
version
we
stated
a
fixed
size
for
the
rule
id
of
8
bits.
C
The
idea
is
to
allow
the
most
suitable
rule
id
size
to
be
decided
and
used
for
each
specific
environment,
and
also
we
would
like
to
avoid
like
a
hard
limit
on
which
could
be
the
network
size
and
number
of
endpoint
pairs
that
can
benefit
from
chic
header
compression
by
the
way,
just
in
case
I'm
seeing
my
screen
like
full
size.
So
I
cannot
see
if
there's
anyone
in
the
queue.
C
So
if
there's
anyone
just
let
me
know
so,
then
the
next
updates
are
in
section
5.1,
which
focuses
on
ipv6
udp
header
compression,
so
by
default.
C
What
is
known
here
is
use
section
10
of
the
base
chic
specification,
which
is
rfc
8724
to
compress
ipv6
or
udp
header
fields.
However,
there's
a
bit
of
a
problem
with
ipv6
addresses
and
udp
ports,
because
chic
is
based
on
the
lp1
architecture
and
in
that
case,
there's
special
terms
and
elements
such
as
the
ones
shown
in
the
figure
where
at
the
left,
you
have
constrained
devices
which
would
adopt
the
role
of
deb
and
on
the
right.
We
have
network
site
infrastructure
which
would
adopt
the
the
role
of
app.
C
So
in
the
base
shake
specification,
the
devon
up
terms
are
used.
Actually
the
rules
for
compression
and
decompression
are
written
for
the
ipv6
addresses
and
udp
ports
in
terms
of
who
is
dead
and
who
is
up,
and
actually
there
is
no
mention
of
source
or
destination.
C
C
However,
the
problem
may
arise
in
other
scenarios
like
two
peers:
two
constrained
devices
that
talk
to
each
other
within
a
mesh
topology,
because,
according
to
the
definition
of
a
depth,
if
both
endpoints
are
constrained,
devices
both
could
have
the
role
of
depth.
So
here
we
need
to
address
this
problem,
so
one
possible
solution,
which
is
the
one
that
is
currently
in
the
last
update
of
the
draft,
which
has
been
discussed
in
lt1
interims,
is
that
we
might
want
to
tell
a
node
whether
it
is
dead
or
up
in
advance.
C
So
in
zero.
Two.
Currently
we
have
this
approach.
We
remove
some
sort
of
tentative
solution
that
we
attempted
in
the
previous
version
in
zero,
one
which
was
using
the
terms
source
and
destination
in
the
rules.
However,
this
would
have
the
issue
of
duplicating
the
number
of
rules,
because
we
would
need
one
rule
for
each
direction
and
well,
we
also
attempted
to
use
transmit
and
receive
as
possible
replayments
replacements
for
applying
and
downlink.
G
C
Yeah,
so
actually
that's
my
current
idea,
and
I
understand
that
these
corresponds
to
what
has
been
suggested
so
far,
well,
that
there
have
been
like
different
suggestions
in
the
lp1
interims,
but
this
is
one
approach
which
reuses
the
functionality
of
devon
up,
mostly
as
it
is
and
yeah.
So,
since
the
rules
need
to
be
written
beforehand,
then
I
understand
that
the
context
to
know
whether
node
will
be
never
up
even
for
different
endpoints.
I
think
it
can
also
be
established
beforehand
as
well.
C
G
C
Yeah,
that's
a
good
point
and
actually
it's
considered
in
as
light.
I
have
next
as
next
steps
yeah
exactly
thank
you
yeah.
So
actually
we
are
trying
to
be
a
bit
generic
so
far
in
the
specification
trying
to
capture,
perhaps
from
small
networks,
to
larger
networks,
so
yeah
at
the
moment,
we
are
trying
not
to
limit
anything
in
this
regard
and
yeah.
One
related
point
is
the
one
you
just
mentioned
about
whether
rules
could
be
shared
or
something
like
that
and
and
even
reused
across
different
pairs
of
endpoints
yeah.
C
Okay,
thank
you
for
the
comments.
So
then
also
another
addition
in
zero.
Two
is
regarding
some
text
in
the
basic
specification
which
states
that
the
iid
cda,
which
means
compression
decompression
action,
cannot
be
used
on
lp1
technologies
that
only
carry
the
depth
identifier
in
the
data
frame.
However,
in
15.4
now
we
explained
in
zero
2
that
data
frames
carry
both
a
source
and
a
destination
field.
Therefore,
the
app
id
can
actually
be
used.
Of
course,
if
the
id
can
be
reconstructed
based
on
information
available
at
the
l2
header.
C
So
because
this
specification
doesn't
define
new
header
compression
functionality
beyond
the
one
in
the
basic
specification,
the
security
considerations
of
section
2.1
in
the
basic
specification
which
focus
on
header
compression,
apply
here
and
we've
added
also
that
the
security
considerations
of
section
9
of
fc
8824,
which
is
chic
for
co-op
header
compression,
also
apply,
because
we
also
want
to
be
able
to
use
co-op
a
compression
here
and
also
we've
added
a
requirement
in
8824,
which
is
that
cryptographic
integrity
protection
is
required
to
protect
chic
headers.
C
So
here
we
also
copy
the
same
requirement
and
in
fact
we
explain
that
in
15.4
networks,
there's
also
support
for
linkedin
encryption
and
authentication.
So
it's
possible
to
support
this
requirement
so
as
possible
next
steps.
Well,
it
would
be
good
to
try
to
stabilize
on
the
discussion
about
devnap
and
writing
the
rules
accordingly,
perhaps
beforehand
as
kirsten
mentioned,
then
subsequent
questions
could
be.
Okay.
Do
all
nodes
need
to
store
all
the
rules
that
need
to
be
used
in
the
network
or
perhaps
is
it
possible
to
reuse
rule
ids
across
these
joint
pairs
of
end
points?
C
C
So
perhaps
we
might
want
to
approach
first,
the
one
hop
case
and
the
mesh
under
case
and
perhaps
leave
route
over
at
least
for
ipv6
udp,
for
maybe
a
later
specification.
So
well.
This
is
perhaps
another
point
to
to
discuss
and
well
other
than
that,
since
most
of
the
content
and
the
main
goals
and
the
structure
of
the
document
has
been
stable
at
the
moment
or
is
getting
stable,
then
the
authors
would
like
to
ask
the
working
group
whether
it
could
be
a
moment
a
good
moment
for
adoption.
G
Yeah,
so
I
think
this-
this
is
a
really
interesting
word
custom
again
by
the
way.
Sorry,
I
think
you
as
an
author,
you
probably
want
to
make
one
or
two
more
rounds,
completing
the
architecture
before
you
push
this
into
the
working
group,
because,
as
an
author,
you
have
more
flexibility
in
doing
this,
so
I
would
probably
look
at
this
at
ihf
114,
but
that's
just
my
personal
opinion.
If
I
were
author
of
this,
I
would
not
ask
for
adoption
today,
but
try
to
make
sure
this
is
complete.
C
A
Here
we
go
native
address
short
address,
yeah
I'll,
give
you
I'll
give
you
the
control,
let's
see
if
it.
A
J
Okay,
okay,
so
I'll
give
you
an
update
on
the
lysix,
slow
native
short
address
draft
okay.
J
This
is
for
the
next
okay.
A
Let's,
let's
do
that
properly,
then
let
me
see,
I
think
you
have
to
exit.
I
can't
take
it
away
from
you.
J
J
That's
great:
that's
the
the
right
deck,
so
that's
another,
an
update
since
one
one
two.
We
submitted
two
revisions,
one
in
december,
one
before
the
cut-off
date
in
in
march,
so
not
that
long
ago,
so
the
main
changes
between
zero
zero,
zero
one.
This
is
the
one
submitted
in
in
december.
J
We
did
quite
a
lot
of
text
revision.
We
clarified
the
the
scope
y
is
in
scopo.
We
believe
is
the
scope
of
the
six
law
working
group,
because
we
don't
actually
do
really
routing,
but
it's
more
on
a
stateless
forwarding
solution,
but
the
main
point
is
really
addressing
and
how
we
build
addresses.
Okay.
J
We
clarified
the
applicability
of
the
solution
for
this
thanks
again
to
pascal.
That
did
help
a
lot
in
in
in
to
in
the
text
in
order
to
to
really
be
clear,
and
it's
obvious
that
the
applicability
is
more
in
a
static
deployment,
because
as
soon
as
you
have
a
topology
changes,
you
should
renumber
or
do
routing.
Okay,
we
don't
want
to
do
routing.
The
numbering
is,
is
complicated.
J
Okay
and
we
add
the
text
in
order
to
clarify
the
allocation
function,
which
is
basically
the
function
that
builds
the
addresses
and
some
small
discussion
about
simplicity
versus
optimality,
and
we
have
a
new
code
or
wrong
that
jumped
on
board
main
changes
between
0102,
which
is
the
last
that
been
submitted
again
revised
the
text
added
some
stuff.
J
We
did
some
further
work
about
the
clarification
on
the
applicability
scope
and
we
tried
to
move
it
earlier
in
the
document.
Okay,
so
that
it's
clear
right
away
where
these
solution
can
apply.
What
is
the
use
case?
Basically,
we
try
to
clarify
the
architectural
overview,
the
the
roles
of
the
of
the
nodes,
because
we
have
a
root.
Then
we
have
for
other
sleeves.
We
try
to
to
better
define
the
different
roles
and
what
each
node
is
expected
to
do.
Okay
and
he
for
the
address
assignment
procedure.
J
We
added
two
neighbor
discovery
options
which
I
will
detail
in
the
following
slides.
So
the
idea
is
or
to
leverage
on
nd
are
already
available
in
the
sixth
slope
and
okay,
the
basically.
We
are
two
simple
options:
okay,
to
request
an
address,
and
as
I
reply
to
assign
an
address
from
the
parent
node,
so
we
call
it
nsa,
request,
address
option
and
nsa
assign
address
option.
Okay,
this
means
we
updated
the
yana
section
with
the
right
format
to
request
this
to
allocate
the
options.
J
J
What
we
have
is
basically
here
is
the
address
here
is
the
lifetime
that
I
give
to
you,
and
here
is
the
prefix
length?
Okay
and
then
there
is
the
actual
address
full
format
and
then
the
node
is
able
actually
to
store
retrieve
the
prefix,
because
all
the
information
plus
the
nsa
address
okay,
because
it's
because
of
the
peculiar
format,
it's
very
easy
to
extract
it
from
the
from
the
full
address.
Okay
details
on
the
in
the
draft
anyway.
J
So
on
the
next
step,
you
will
see
the
evaluation
in
the
next
presentation:
okay,
rock
the
league
one.
Thank
you.
We
will
give
a
short
demo.
We
try
to
evaluate
a
little
bit
how
much
and
where
is
the
game?
With
this
approach,
we
we
need
to
incorporate
further
feedback
that
we
received
actually
actually
after
the
latest
submission.
So
we
have
diane
carter
and
carpenter
adnan
interesting
feedback.
I
have
to
say
so.
J
All
in
all,
we
believe
the
the
core
of
this
document
is
stable,
but
we
need
a
revision
of
of
that
document
for
the
the
feedback.
Okay,
we
expect
to
do
it
right
away
after
one
or
three,
because
already
we
have
the
feedback,
and
at
that
point
we
may
consider
adoption
or
a
working
group
adoption,
because
again
we
the
core
elements
are
stable.
J
C
J
C
B
C
K
Hello
to
answer
this
question
from
class
accepted,
you
accepted
the
bill
plc
and
how
there
is
another
fiscal
year.
Technology
named
apl,
advanced
physical
layer,
which
is
based
on
the
standard
standard
standardization
of
ioe
802.3
ct
is
also
suitable
for
this
nsc
technology
in
the
network
layer.
I
think.
C
K
I
K
B
As
a
quarter
and
also
from
the
perspective
of
the
operators,
so
we're
working
how
to
use
app
address
in
most
scenarios,
so
I
think
it's
a
really
good
way
to
apply
the
short
appeal
address
without
an
unnecessary
routing
function
in
iot.
So
maybe
I
hope
the
wg
could
consider
this
work.
Yeah
thanks.
That's
all.
K
Okay,
thanks
hello,
everyone
and
this-
and
this
is
for
the
demonstration
of
the
nsa
allocation
function
and
which,
which
is
just
which
is
described
in
the
draft
of
native
shorter
address
version
2.
next
page.
Please.
K
K
Caseback
is,
but
all
nodes
under
the
sim
root
must
use
the
sim
one
see
section
four
in
the
draft
and
for
the
example
algorithm
for
the
location
function
is
given
in
the
draft
is
very
simple
and
today
I'll
show
the
demo
implemented
based
on
this
algorithm,
and
so
the
target
address
will
be
allocated
by
parent
parent
address,
plus
plus
some
some
binary
one
binary
ones
and
plus
the
rule
bit
which,
which
indicate
indicated
the
node
is
leaf
or
for
order,
and
the
third
point
is
about
to
calculate
the
maximums
of
the
address
and
the
maximum
of
the
address
for
a
node
equals
the
length
of
the
parent
address,
plus
the
length
of
the
ones
and
plus
one
bit.
K
Next,
please
thank
you,
and
the
code
is
very
simple.
We
can
see
in
the
slide
only
one
page
for
the
core
code
for
the
core
code
of
implemented
allocation
function
and
most
of
the
parameters
used
by
the
allocation
function
is
a
is
a
lo.
The
local
is
a
local
variables
and
only
the
parent,
only
the
parent
address
is,
is
a
global
context.
A
K
No
okay,
okay,
so
there
are,
there
are
two
keys.
Two
keys
designed
for
the
demo
case.
One
is
to
generate
a
topology
and
send
addresses
for
the
topology,
and
the
parameters
is
will
be
set,
is
layers
or
in
the
topology
of
the
tree,
and
the
second
parameter
is
maximum
children
of
of
of
each
code.
Sorry,
so
here
we
give
an
example
of
a
four
layer
tree
topology
and
for
every
node.
How
have
four
children?
K
Because
because
we
choose
the
random
random
mode,
so
not
not.
Every
node
has
has
a
full
amount
of
the
children
so
for
the
output
of
the
program
we
can
see,
there
are,
there
are
totally
23
nodes
and
the
maximum
address
length
is
six
owned
by
the
blue
nodes
and
the
average
average
length
of
the
addresses
is
only
four
four
bits.
K
So
as
so,
and
this
will
will
prove
the
the
efficiency
of
the
allocation
function
is
very
high.
Okay.
Next,
please
we'll
go
to
case
two
focus.
Two.
The
program
will
read
a
arbitrary
graph
from
a
file
and
try
to
allocate
nsa
addresses
for
for
the
file,
and
there
are
totally
21
21
nodes
in
in
the
input
file
and
after
the
allocation
we
can
see
the
correct
the
correct
nsa
addresses
had
been
successfully
allocated.
K
K
K
We
can
feel
larger
numbers,
but
because
display
display
problems,
so
we
use
four
and
and
four,
as
example,
and
we
can
use
a
random
and
generate
generated
the
topology
and
evaluate
the
length
of
the
devices
and
there
are
16
nodes
and
every
address
length
is
only
three
bits
and
the
maximum
length
is
six
and
we
can
draw
this,
so
we
can
see
and
the
max
the
maximum
length
is
six
and
the
in
for
the
balloons
after
we
have
after
we
have
this,
and
this
tree
and
the
the
nodes
can
calculate
the
next
hope
that
there's
a
destination
address
and
not
rely
on
the
separate
and
separate
routing
table
and
for
case
2
we
can
load.
J
K
Oh
okay,
cody
space
and
I
see
product
and
the
example
topology.
Okay,
we
can
see
the
addresses
are
allocated
successfully
and
the
output
file
is
generated
and
okay.
This
is
the
input
file
we
can
see.
No
no
addresses
is
labeled
for
the
nodes,
but
after
allocation
we
can
see
the
address.
The
ac
address
is
labeled
for
every
for
every
node
here,
okay
and
that's
the
whole
demonstration
here,
any
questions
or
comments.
Thank
you.
F
Okay,
let's
stay
for
information,
then
I
can
see
where
it
can
be
useful.
F
In
specifically,
hardware
environments
like
or
if
you
look
at
the
harness
where
every
uid
every
every
device
has
a
very
fixed
position
in
a
kind
of
an
electrical
wiring,
then
I
can
see
that
this
amplifies
the
rod
inside
the
harness
and
avoids
having
a
point
to
point,
I'm
sorry,
a
star
typology
on
the
harness
which
consumes
more
copper.
So
I
really
can
see
how
this
can
be
useful.
F
So
basically,
what
I'm?
What
I'm
saying
is:
iot
environments,
we
like
redundancy
and
you
talked
about
safety
networks,
etc.
Safety
network
condition
one
it's
redundant,
and
so
please
consider
how
you
would
build,
not
one
but
two
trees
and
and
different
addresses
and
redundancy,
and
that
would
make
it
really
suitable.
K
F
K
F
Because
you
know
the
writing,
the
path
of
the
packet
along
the
graph
is
exactly
my
point.
The
path
of
the
packets
along
the
graph
is
limited
because
of
the
addressing
right,
because
you
have
to
follow
the
addresses.
It's
my
understanding.
You
don't
have
a
routing
protocol,
so
if
you
basically
want
to
use
two
different
non-concurrent
paths
to
the
same
device,
you
need
to
give
it
two
addresses
on
two
different
topologies
make
sense.
No
sense.
We
can
follow
the
mailing
list.
F
My
understanding
is
that
it
is
constrained
by
the
address
as
following
the
bits,
basically
so
the
path,
the
effective
path
in
this
mesh
is
a
tray,
and
I
see
that
as
a
limitation,
because
we
we
want
redundancy.
So
what
I
encourage
you
to
look
at
is
something
like
giving
two
addresses
to
the
device
to
build
two
trees
which
would
not
be
congruent
so
that
each
address
can
be
reached,
even
if
there
is
a
failure.
Otherwise,
you
know
you
break
someone
in
the
tree.
The
whole
sub
tree
is
disconnected.
K
Why
does
this
connection
occur?
Because
our.
K
Scenario
is,
is
more,
is
a
stable
topology.
If
maybe.
I
F
F
F
The
next
version
of
this
draft,
if
you
could
show
how
you
build
two
trees
and
and
find
the
two
paths
non-concrete.
So
probably
you
have
two
addresses,
then
then
that
would
give
you
a
real
that's
my
suggestion
for
you.