►
From YouTube: IETF108-6LO-20200729-1300
Description
6LO meeting session at IETF108
2020/07/29 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
A
A
The
second
presentation
is
on
the
status
of
the
ipv6
of
the
plc
draft,
which
will
be
given
by
remy
after
that
we'll
have
a
presentation
on
the
update
of
the
six
law
applicability
and
use
cases
draft
by
yagoon,
and
then
we'll
have
a
presentation
of
an
updated
version
of
a
drafting
title
design.
Considerations
follow
power,
internet
protocols.
So
perhaps
some
of
you
may
remember
that
couple
of
years
ago
there
was
an
initial
presentation
of
this
draft
in
six
law,
and
now
there
has
been
a
date.
A
B
A
A
Time
draft
here
there's
an
important
point,
which
is
that
perhaps
some
of
you
may
remember
the
authors
realized
there
was
some
issue
with
how
modular
arithmetic
was
being
used
in
the
draft,
so
they
proposed
a
number
of
updates
and
those
proposal
dates
were
shared
on
the
mailing
list
and
there
was
no
objection
from
the
working
group
on
those.
However,
the
updates
are
not
yet
in
the
draft
in
the
last
revision,
which
is
zero
five,
so
we
have
a
question
for
our
ad
eric,
which
is
that
we
understand
that.
A
A
A
These
all
the
these
documents,
the
last
four
and
the
previous
one
correspond
or
belong
to
the
cluster
310.
So
perhaps
it
will
not
be
surprising
to
see
the
publication
of
all
of
them
almost
simultaneously,
then
the
next
document
is
ipv6
over
nfc.
So
you
may
recall
that
this
document
was
evaluated
by
the
isg.
A
Then
there
were
some
disgust
bullets.
The
authors
updated
the
draft
and
in
the
role
of
as
the
shepherd
I
made
a
review
of
the
draft
considering
some
of
the
comments
from
the
isg
so
then
well,
there
was
some
extension
extensive
review
here.
There
were
perhaps
some
issues
about
the
tone
of
the
document.
Some
editorial
improvements
required
also
a
couple
of
technical
points.
So
then
the
authors
updated
the
draft
version.
The
last
version
is
16
and
well
as
the
shepherd.
A
C
A
A
A
Or
well
yeah,
it
seems
like
this
is
the
yeah
okay.
This
is
the
last
slide,
so
just
some
quick
report,
some
recent
news
on
some
recent
interests
on
ipv6
over
bluetooth,
low
energy.
As
you
know,
six
lock
has
been
working
in
this
area
signal
produced
rfc
7668,
which
specifies
ipv6
over
star
topology
ble
networks,
and
also
we
have
been
working
on
the
dle
mesh
extension,
which
is
extending
the
previous
rfc
to
mesh
topology
networks.
A
So
it
seems
like
perhaps
the
bluetooth
seat
is
considering
a
different
technical
approach
and
perhaps
that
might
lead
to
some
of
the
work
in
six
law.
However,
that
still
remains
to
be
seen,
so
I
guess
that
we
will
learn
a
bit
more
about
that
in
the
next
upcoming
months.
So
is
there
any
question
any.
A
D
E
Okay,
so
the
last
call
for
this
draft
was
initiated
on
april
the
20th.
Since
then,
we've
received
comments
from
ego
and
makeup.
So
many
thanks
to
ego
and
michael
and
actually
ego
has
raised
an
editorial
comment.
Basically,
it
is
about
the
reference
for
actual
e
1901.1,
we've
updated
it
to
the
correct
link
and
the
next
page
next
step.
Please.
E
E
E
E
Only
in
the
link
local
address
and
the
id
drive
from
short
address
can
be
used
to
generate
ipv6
address,
to
communicate
with
the
public
network
and
thus
the
mac
address
of
a
plc
address.
A
plc
device
is
not
exposed
to
the
to
the
public
network
and
mecca
suggested
to
include
another
solution,
as
per
rc80
64,
to
generate
a
stable
ipv6
address
using
opec
id,
which
is
basically
a
hash
measure,
a
hash
method
to
generate
the
opec
interface
id
so
that
the
privacy
of
the
device
is
protected,
and
next
page.
E
Please
next
page,
please
oh
yeah,
yeah.
The.
The
third
comment
is
about
to
include
the
previous
prefix
information
option
in
the
router
advertisement
or
not
when
the
plc
network
is
using
l3
routing,
it
was
a
must
not
in
the
previous
version.
However,
there
is
the
mass
nut
was
because
that
to
we
want
to
avoid
the
conflict
between
the
prefix
given
in
the
dio
message
and
the
prefix
given
in
the
router
advertisement.
E
However,
there
is
a
special
case
in
the
draft
raw
unaware
leaves
the
leaf
devices
can
can
run
without
the
ripple
at
all.
So
in
this
case
the
prefix
has
to
be
encapsulated
in
the
root
advertisement
instead
of
the
deal
message.
So
in
this
case
the
prefix,
the
pio
should
be
encapsulated
in
the
router
advertisement
message
and
next
page.
Please.
E
E
A
A
A
A
D
D
D
D
D
Say
to
dominic
he
revealed
and
gave
him
gave
many
comments
for
this
draft,
and
his
command
was
very
helpful
to
improve.
So
I
tried
to
resolve
his
command
and
then
I
got
a
comment
from
roland.
His
command
was
related
to
pearce
technology
and
after
published
the
90th
version.
I
also
got
a
comment
from
living.
D
D
D
D
Please
and
automatic
also
based
the
ambiguous
expression
of
plc.
Plc
is
wired
technologies
among
six
rule
nuclear
technologies,
so
pierces
are
different
capabilities
compares
to
wireless
technology.
So
I
understand
that
in
the
previous
expression
has
some
ambiguity
so
to
remove
this
ambiguity,
I
modified
a
sentence.
D
So,
unlike
so,
I
want
to
release
the
multiplication
sentence
on
plc's
data
transmission
technique
that
utilize
power
conductor
as
video,
unlike
other
dedicated
communication
infrastructure
power
conductors,
are
widely
available
indoors
and
outdoors.
Moreover,
wire
technologies
cause
less
interference
to
the
radio
medium
than
wireless
technologies
and
are
more
reliable
than
their
wireless
counterpart.
D
D
So,
in
the
previous
version
of
this
threat
we
consider
the
ltch
mpc
technology
as
a
circular
nuclear
technology.
But
after
the
revision
we
decided
to
remove
the
ltc
mpc.
So
thanks
to
dominic,
so
we
delete
the
expression
of
the
possible
candidate
of
the
sixth
role
in
clear
technology
next
page.
Please.
D
So
dominique
also
raised
that
table
of
comparison
between
six
loading
layer
technologies.
It
looks
like
a
mixture
of
technologies
and
applications,
for
example
the
textuality,
if
textually
is
used
for
smart
metering,
but
it
actually
also
can
be
used
to
other
applications,
for
example
home
automation.
D
So
in
this
case
there
are
requirements
and
the
characteristic
is
a
little
different.
So
yes,
I
agree,
but
in
some
point
we
have
a
difficult
to
capture
common
characteristic
of
each
technologies
for
different
applications
in
limited
space.
So,
as
you
can
see,
I
in
the
first
row
we
described
the
uses
of
each
technologies.
D
D
And
yeah
this
is
the
the
last
command
domain.
It
says
that
this
is
the
use
case
description,
so
any
normal
references
except
the
rfc
2191
can
move
to
informative
references.
So
I
look
over
the
rfc
7322,
so
in
document
the
normative
references
are
essential
to
implementing
or
understanding
the
contents
of
rfc
and
and
informers.
References
provide
additional
information.
D
D
D
F
Thanks
young,
I,
since
carlos,
is
the
co-author
of
this
draft
and
we
have
gone
through
one
round
of
a
group.
Last
call
last
time-
and
I
see
we
have
addressed
all
the
comments
that
has
been
received
so
far.
We
can
do
a
shorter
second
work.
Group
last
call
before
progressing
the
draft
unless
there
is
any
objection
from
the
work
group.
C
C
A
A
A
A
G
So
this
actually,
this
slide
actually
has
four
bullets
on
it,
and
so
basically
the
outline
is
that,
from
this
work
we
had
finding
number
one
was
that
six
lowpan
implementations
do
not
completely
interoperate.
Finding
two
was
that
we
noticed
that
this
was
actually
in
large
part
because
of
code
size
issues.
G
Finding
three
was
that
we
believe
that
traditional
protocol
design
principles
lead
to
bloated
code
in
some
instances
and
then
sort
of
the
contribution
of
this
work
is
three
low
power
protocol
design
principles
that
we
think
can
solve
this
next
slide.
Please-
and
this
has
three
bullets
so,
and
the
main
thing
that
we
have
actually
added
to
the
updated
version
of
the
draft
is
an
evaluation
of
the
principles
and
to
go
about
this
evaluation.
G
G
And
this
has,
I
think,
four
bullets,
sorry
and
what
we
found
was
that
each
implementation
could
communicate
with
the
broader
internet.
But
we
found
that
in
many
cases
they
unfortunately
couldn't
talk
to
each
other.
So
this
is
a
wireshark
screenshot
of
an
embed
device,
sending
a
contiki
device,
a
6lowpan
packet
that
contains
an
ipv6
extension
header
and
although
the
contiki
device
sends
an
acknowledgement
at
the
link
layer,
it
silently
drops
the
packet
at
the
network
layer
next
side.
G
Please,
and
what
we
actually
found
is
that
we
could
find
examples
like
that
previous
one
between
every
possible
pairing
of
six
lowpan
stacks.
So
what
we
specifically
found
was
that
for
each
pairing
of
stacks
we
could
generate
packets
that
were
valid
according
to
the
6lowpan
standards,
but
dropped
by
a
different
receiving
stack.
G
G
So
there's
sort
of
lots
of
examples
here,
like
you'll,
see
tinyos
supports
udp
checksum
elision,
but
if
tinyos
is
configured
to
use
this
feature
and
sends
a
packet
to
a
contiki
device,
contiguo
will
drop
it
because
it
does
not
support
checksum
malign.
Similarly
embed
supports
ipv's
extension
headers,
but
riot
does
not
so
a
communication,
including
the
destination
options.
Header,
for
example,
would
lead
to
a
dropped
packet
and
there
are
a
bunch
more
examples.
I
had
you
probably
have
to
just
click
forward
a
few
times.
G
E
A
G
G
And
we
then
wanted
to
connect
that
to
the
flash
size
that's
available
on
iot
platforms
today.
So
this
is
a
listing
of
several
15.4
supporting
iot
platforms
available
in
the
last
eight
years,
and
we
find
that
it
spans
a
reasonably
broad
range
from
as
low
as
64
kilobytes
on
a
really
low
cost
device,
like
the
emv
wmb
to
as
much
as
512
kilobytes
on
a
sort
of
more
resourceful,
perhaps
more
expensive
device
like
the
nrf52840
and
while
in
research
code
size
is
rarely
an
issue
in
real
world
deployments.
G
Use
we
then
wanted
to
compare
sort
of
that
previous
table
with
the
size
that's
required
by
6lowpan
stacks
today.
So
what
we
found
looking
at
the
6lowpan
code,
size
of
each
of
the
stacks
that
we
implemented,
is
that
they
actually
span
a
pretty
broad
range,
with
some
of
the
more
complete
stacks
like
embed
and
thread
requiring
as
much
as
26
kilobytes.
G
So
principle,
one
is
capability
spectrum
and
basically
says
that
low
power
protocols
we
believe,
should
support
both
ultra
low
energy
devices,
as
well
as
devices
with
very
limited
code
space
and
rather
than
all
devices
paying
the
code.
Size
costs
of
complex
energy.
Optimizations
protocols
should
support
a
linear
spectrum
of
device
capabilities
principle.
G
And
finally,
we
wanted
to
evaluate
the
principles
specifically
to
answer
these
three
questions,
so
one
can
capability
levels
provide
a
good
range
of
implementation
complexity,
two.
What
is
the
overhead
of
capability
of
capability
discovery
and
three?
Is
a
linear
capability
spectrum
really
better
than
some
form
of
arbitrary
feature
selection
in
which
nodes
can
communicate
any
features
that
they
want
to
use
out
of
the
entire
set?
G
But
higher
levels
like
five
include
more
complex
things
like
compression
of
ipv6
extension,
headers
principle:
two
is
capability
discovery,
and
for
that
we
in
our
implementation.
We
used
a
new
neighbor
discovery
option
in
router,
solicitations
and
neighbor
advertisements
and
a
new
icmp
v6
message:
type,
six,
lowpan
class,
unsupported
and
then
finally,
principle
three
is
provide
reasonable
bounds.
There's
details
in
the
draft,
but
I'm
not
going
to
go
into
it
here
because
of
time
concerns.
G
So
we
implemented
all
of
these
changes
in
contiki
and
g6.
Lopen
stack
required
changing
about
500
lines
of
code
and
what
we
found
was
a
that
capability
levels
could
provide
a
good
range
of
implementation
complexity,
the
spectrum
spans
a
nearly
100
percent
increase
in
code
size
from
level
zero
to
level
five.
We
chose
contiki
and
g
because
it
was
the
smallest
stack
out
of
all
of
those
that
we
analyzed,
so
any
savings
would
be
sort
of
most
pronounced
here.
G
Selection
has
significant
run
time
costs
because
low
capability
nodes
cannot
compress,
cannot
compress
icmp
responses
to
higher
capability
nodes
that
send
them
messages
that
they
can't
decode,
and
the
reason
for
this
is
that
low
capability
nodes
do
not
have
a
guarantee
that
the
node
that
they
are
receiving,
something
from
actually
supports
all
of
the
features
which
they
might
want
to
use
in
compressing
a
response,
and
so
arbitrary
feature,
selection
actually
forces
that
all
icmp
errors
be
sent
completely
un
uncompressed,
which
is
a
significant
cost,
so
yeah.
In
conclusion,
we
found
low
power.
G
While
we
did
apply
these
principles
to
six
slope
and
I'm
not
actually
directly
recommending
these
changes
to
the
six
open
protocol,
but
just
thought
that
this
could
be
some
interesting
information
for
all
of
you
and
that
you
might
have
some
interesting
responses.
I
sent
out
the
updated
version
of
the
draft
on
the
6l
mailing
list,
so
any
feedback
that
you
guys
have.
I
would
really
appreciate
thanks.
A
A
G
C
Hudson
I
I
apologize,
I
haven't,
haven't
read
the
graph,
that's
right,
you
presented
some
implications
for
code
size
and
you
also
make
a
claim
here
on
the
final
slide
about
energy
use.
Did
you
did
you?
Did
you
actually
was?
Are
there
comparisons
about
the
energy
use
about
the
about
this
protocol
thing
the
nd
option
or
the
hdra.
G
So
the
total
bytes
added
in
the
common
case
for
high
capability
devices
is
still
small
and
the
the
there
are
no
additional
packets
required
to
be
sent
or
is
the
generation
of
icmp
errors,
so
the
generation
of
icmp
errors
are
additional
packets
where
currently
nodes
would
simply
silently
drop
the
packets.
My
argument
would
generally
be
that
getting
errors
instead
of
silent
drops
is
generally
desirable
in
these
networks.
E
C
G
A
A
A
A
A
A
A
So
in
order
to
keep
overhead
low,
we
might
consider
allocating
a
whole
page
for
chic
header
compression,
since
anyway
pages
are
currently
quite
unused
other
than
page
zero
and
a
little
bit
page
one.
So
it
would
mean
the
sheet
dispatch
pattern
of
four
ones
and
then
some
combination
of
four
bits
to
be
determined.
A
This
would
allow
a
one
byte
sheet
dispatch
pattern
and
then,
for
example,
there
could
be.
Oh,
is
offline.
Well,
basically,
that's
the
main
idea,
so
it
might
be
in
the
best
case
possible
to
have
a
dispatch
and
also
the
compressed
header
in
two
bytes.
So
well.
I
guess
that
we
may
continue
discussion
on
this
on
the
mailing
list
and
well.
It
would
be
great
to
hear
your
feedback
and
comments
on
this.
A
H
H
I
Yeah,
so
I
think
also
it's
a
good
idea.
I
think
the
discussion
will
be
very,
very
difficult
with
you,
because
your
voice
is
very
cut,
and
so
I
will
go
to
the
mailing
list,
but
I
I
support
this
and
I
will
maybe
we
will
need
also
header
compress
to
keep
ipv6
compressed
as
a
s6
low
and
to
put
chick
for
the
upper
layers.
I
A
Okay,
I
hope.
Well,
I
don't
know
if
you
cannot
hear
me:
okay
yeah,
so
I
don't
know
if
anyone
is
correctly
is
able
to
correctly
hear
my
audio.
So
I
guess
that
it
is
the
time
to
to
finish
the
session
thanks
to
everyone
who
has
attended
and
let's
definitely
continue
discussing
on
the
mailing
list.
Apologies
for
any
issues
with
the
audio.
I
have
no
clue
why
they
have
been
happening
but
yeah.
Let's
continue
discussion
on
the
mailing
list
and
hope
to
see
you
soon
in
another
meeting
soon.