►
From YouTube: IETF106-6LO-20191120-1330
Description
6LO meeting session at IETF106
2019/11/20 1330
https://datatracker.ietf.org/meeting/106/proceedings/
A
C
A
D
Okay,
hello,
everyone
welcome
to
of
the
six
low
working
group.
Please
make
sure
that
you
are
in
the
red
room.
My
name
is
Carlos
Gomez.
This
is
sri
tapan
dari
and
our
responsibility
is
suresh
krisshnan,
so
we
have
a
minute
taker,
Dominique,
kindly
volunteered
to
take
a
minute.
So
thank
you
very
much
Dominique
and
Pascal.
Also,
thank
you
very
much
and
by
the
way
we
understand
that
you
know
taking
will
happen
over
the
ether
pad
so
feel
free
to
join
the
it's
a
pad
to
contribute
to
the
collaborative
process
of
taking
minutes.
D
D
D
This
is
the
usual
note.
Well,
it
contains
a
number
of
pointers
to
ITF
policies
on
important
topics,
so
please
make
sure
that
you
have
read
it,
and
this
is
the
agenda
proposed
for
today.
So
the
first
slot
is
the
usual
chairs,
introduction
and
report
of
the
working
group
document
status
after
that,
the
second
slot
is
dedicated
to
the
fragmentation
related
draft,
which
will
be
presented
by
Pascal.
Here
we
would
like
to
propose
change
compared
with
the
agenda
that
was
originally
announced.
D
D
Okay?
Thank
you.
So
then
the
next
presentation
will
be
the
update
of
ipv6
mesh
over
ble
links
after
the
shepard
review.
The
next
one
will
be
the
presentation
of
the
date
of
the
sixth
low
applicability
and
use
cases
document
presented
by
jung-geun
home
and
after
that,
we'll
have
the
presentation
of
the
update
of
ipv6
over
PLC
draft
by
Remy.
D
After
that,
we
have
the
first
presentation
of
a
new
draft
which
is
entitled
ipv6
over
controller
area
network.
This
will
be
a
remote
presentation
given
by
Alexander
and
after
that
we
have
yet
another
presentation
of
a
first
version
of
a
draft
which
is
entitled
comparison
of
six
low
and
chic,
which
will
be
presented
by
a
low
hon.
D
Finally,
we'll
have
a
presentation
of
the
draft
entitled
a
symmetric
ipv6
for
IOT
networks,
so
this
is
an
update
after
the
previous
presentation
that
was
held
in
Montreal.
By
the
way
you
can
notice
that
the
2
last
slots
in
the
agenda
correspond
to
considering
alternative
techniques
for
header
compression,
for
example.
So
we
expect
to
have
a
nice
discussion
on
this
topic.
Is
there
any
comment
on
the
agenda.
D
Ok,
thank
you.
So
now,
let's
go
through
the
report
of
the
working
group
documents
status
and
this
will
be
presented
in
decreasing
order
in
terms
of
maturity
as
usual.
So
first
of
all,
we
have
the
packet
delivery
deadline.
Time
document,
which
is
in
the
RFC
editor
queue.
That's
because
it
is
awaiting
the
publication
of
the
60-ish
architecture
document
which
will
be
normative
in
this
document,
and
the
next
one
is
ipv6
over
NFC,
which
is
in
AD.
D
Follow
up
I,
don't
know
if
you
want
to
yes,
so,
as
you
may
recall,
this
draft
was
evaluated
by
the
ASG.
There
were
a
few
discuss
positions
and
the
authors
dated
the
draft
and
actually
replied
to
the
ASG
members
who
had
made
comments
and
he
should
discuss
ballots.
However,
the
status
of
the
document
has
not
changed
since
then.
In
fact,
we
have
not
received
feedback
from
the
is
G
since
Montreal,
so
perhaps
H
is
there
any
hint
on
when
we
might
get
feedback.
E
I'll
take
a
shot
at
like
you
know
the
first
six
months
right
so
back
in
the
deadline
time
and
we
found
mathematical
error
in
the
deadline
time.
Calculation,
it's
been
approved,
it's
in
Dallas
area.
Thank
you.
So
there's
something
I
need
to
update.
The
ID
is
John.
There's
some
new
text
thanks
a
lot
for
charlie
working
on
it
like.
So
we
need
to
talk
to
you
about
it
a
little
bit
and
so
the
NSC
that
the
biggest
issue
was
the
tone
of
the
document
and
that
caused
a
lot
of
the
discusses.
E
It
looked
a
lot
like
a
marketing
document
for
the
technology.
So
it's
it's
kind
of
being
rewritten
and
I'm
like
talking
to
the
discussing
it
is
to
get
this
geared,
but
I
don't
have
a
clear
indication
of
the
stuff.
That's
needed
to
change
yourself
like
in
the
specific
exchanges,
but
it's
more
about
the
tone
of
the
document.
In
there.
Okay
and
the
AP
nd
I
finished
my
ID
eval
I
haven't
written
up
III
wanted
to
send
it
before
this
week.
E
That's
actually
the
first
thing
on
my
queue
right
like
so
I
once
I,
send
it
to
like.
Hopefully,
Pascal
can
lock
down,
run
very
quickly
on
the
de
panne
D
draft
to
submit
a
day.
There
are
some
changes
that
are
required:
AP,
Indy,
oh,
no,
no,
not
yet
I
haven't
sent
it.
That's
what
I'm
saying
so
so
so
so
what
happened
with
this
draft
is
like
we
were
in
a
I,
Triple,
E
coordination
meeting
and
they
said
they
wanted
to
look
at
it.
E
So
I
was
waiting
on
the
ITP
folks
to
get
back
and
they
got
back
and
said
they
didn't
care
about
it
frankly
right.
So
that
kind
of
like
took
like
a
three-month
detour
and
through
the
coordination
process,
and
so
that's
done
so
once
that's
out
of
my
way.
I'll
get
other
documents
done,
which
are
pretty
simple
compared
to
AP
nd,
that's
for
my
side,
so
that's
covers
the
first
six
documents.
E
D
You
so
then,
there's
the
next
three
documents
which
have
been
recently
entered,
the
the
a
devaluation
state.
So
the
first
thing
is
6lowpan
fragment
forwarding
which,
from
falling
and
from
in
recovery,
so
the
the
first
two
are
the
ones
related
with
fragmentation.
The
first
one,
six
low,
confirm
and
forwarding
has
been
already
evaluated
by
the
internet
area
directorate.
Actually
dave
taylor
provided
review
has
engaged
in
discussion
with
the
author.
So
thank
you
very
much
Dave.
D
So
after
that
we
have
also
the
ipv6
mesh
of
links
document
here,
the
Shepherd
has
done
the
review
of
the
document.
The
authors
have
updated
the
draft
and
provided
that
these
update
satisfies
the
comments
of
the
Shepherd.
Then
the
next
step
would
be
getting
the
Shepherd
right
up.
Then
we
also
have
the
six
low
applicability
in
use
cases
document.
As
you
may
recall,
there
was
a
one
key
working
group
last
call
which
ended
without
feedback
for
this
document
few
months
ago.
However,
recently
there
has
been
some
feedback
on
the
mailing
list.
D
For
example,
Pascal
provided
reviewed
the
document.
So
thank
you
very
much
for
that,
and
also
after
the
deadline,
the
internet
draft
submission
deadline.
There
was
also
some
further
feedback
on
the
mailing
list
by
Remy,
so
today
there
will
be
a
presentation
of
the
latest
revision
of
this
document,
and
the
last
working
group
document,
which
is
the
ipv6
over
PLC
draft,
has
also
been
updated
recently,
so
they
it
will
also
be
presented
today.
Any
comments
or
questions.
E
I'm
glad
there's
like
some
feedback
on
the
use
case
document,
because
I
was
really
and
worried
that
it's
just
gonna
die
because
they're
like
it
didn't,
look
like
anybody
was
interested
in
it.
So
I'm
glad
it's
like
making
some
progress.
I
still
don't
know,
is
there's
like
enough
critical
mass
behind
it
to
take
it
through,
but
I'm
at
least
glad
that's
something
something
is
happening
in
the
space.
F
Okay,
so
I
was
not
sure
initially
that
I
would
need
this
slot
and
then
things
happened.
So
that's
why
I
asked
the
chairs
and
I.
Thank
you
so
much
that
to
make
a
little
bit
of
room
for
the
discussion,
so
we
have
two
fragmentation
document.
What
is
the
minimal
fragment,
which
is
a
very
generic
specification,
does
not
give
implementation
details,
but
global
implementation
recommendation
or
constraints
or
overview
and
the
other
one
is
fragment
recovery
and
the
minimal
fragment
also
discuss
is
a
particular
implementation
or
describe
set
of
points
to
it.
F
F
So
both
past
welcome,
plus
Co,
as
Calais
mentioned,
and
so
I'm,
just
giving
you
the
the
AB
data
of
the
Hawaii
after
death.
So
the
the
thing
that
really
happened
is
that
we
thank
you
Dave
thanks.
So
much
we
had
a
number
of
from
trips
between
me
and
Dave.
Actually
so
I
kind
of
took
over
because
table
was
not
a
variable.
It
was
the
initial
editor,
and
that
actually
is
also
part
of
that
discussion
that
we
had
is
maybe
Tom
and
I
were
not
100%
in
sync
about
the
content
of
this
document.
F
So
that's
why
it's
worth
coming
back
to
the
working
group,
because
we
initially
the
document
did
not
really
have
an
introduction
to
explain
what
it
was
about.
So
that
was
the
first
reason
why
we
had
this
discrepancy,
and
second,
the
most
of
the
text
was
here
is
how
VOB
works
from
from
from
up
there
and
what
he
did
not
do
enough
to.
My
taste,
at
least,
was
to
say
eh
yeah.
F
So
the
feeling
I
had
you
know
on
trying
to
answer
Dave's
point
well
that
this
should
be
described
in
more
detail.
There's
a
need
to
to
tell
the
world
that
ok,
the
ATF
has
looked
at
what
it
is
to
fault
fragment.
There
is
one
particular
way
which
is
described
in
details
down
to
the
implementation,
which
is
VRB,
that's
great.
We
are
being
able
to
do
it
with
RFC
1459
44.
The
weight
stands
now.
There
are
things
that
VR
be
and
any
other
fragmentation,
including
the
reliable
fragment,
needs
to
do
anyway.
F
F
F
F
That
was
designed
at
the
LP
one
working
group,
which
is
a
very
thought-out,
very
well
designed
fragmentation
mechanism,
and
one
could
say
that
it
kind
of
competes
with
this
one
which
I
hope
I
don't
know
in
which
details
are
going
to
go
along,
but
the
bottom
line
is
one,
is
very
optimized
for
one
hub
and
I
think
it
does
a
better
job
than
this
one
if
there
is
just
one
hub
but
the
real
problem
that
this
draft
addresses
is
not
when
it's
one,
because
we
have
to
lay
off
two
acknowledgements
in
most
of
the
six
law
cases.
F
Would
like
to
work
a
group
of
people
like
you,
it's
a
bad
joke!
Okay,
so
so
the
only
comments
we
had
was
implementation
commands
by
Martine.
So
thank
you
Martina.
If
you're
hearing
us
today
so
that
the
discussion
was
it's
interesting,
I
need
to
mention
it,
because
the
question
was
okay.
What,
if
I'm
falling
this
fragment
and
I
hit
the
hub
limit
of
the
packet?
Obviously
I
cannot
fall
it
more
and
you
would
you
would
figure
o?
F
Is
it
different
if
the
packet
is
is
recompose
that
every
up
or
if
it's
fragmented
and
at
the
end
of
the
day
that
brings
up
the
question,
is
of
I?
Have
this
fragmented,
c-clip
and
packet,
and
there
is
an
arrow
with
it
and
the
Euro
may
come
because
it
was
fragmented
or
because
it
was
compressed
by
six
low,
maybe
in
the
wrong
fashion
or
something
or
in
a
fashion
that
the
next
hub
does
not
understand
versus
it's
a
crime
with
ipv6
itself,
like
I'm
tu,
like
in
this
case
up
limit
or
anything
else.
F
How
do
you
report
that
to
the
source
and
it's
even
worse
than
that?
Who
is
the
source,
because
if
your
recomposing
six
the
planet
every
hub
and
the
promised
to
do
with
the
6lowpan
compression
or
fragmentation,
then
maybe
the
source
of
the
prime
is
not?
You
know
the
guy
who
passed
the
packet
at
layer
3
at
the
other
hand,
of
the
mesh
it's
really
hard
before
you.
F
So
how
do
we
process
ICMP
rose
in
general
and
to
whom
we
send
your
back
and
what
goes
into
the
packet,
for
instance,
if
the
problem
is
redo
to
to
the
compression
on
the
fragmentation,
and
you
do
what
Martin
did,
which
is
recomposed
the
packet
and
then
be
on
the
ICMP
error
with
the
recompose
package,
you
lose
all
track
of
what
was
in
the
compressed
form
and
if
Yahoo
was
there,
then
you
lose.
The
information
about
the
error,
so
so
seems
to
me
that
we
kind
of
overlooked
all
this
ICMP
or
game.
F
Mostly
if
you
have
multi
hubs
and
that
could
deserve
some
attention
by
this
group
in
the
future.
So
I
really
I
mean
we
discussed
what
she
could
do.
She
does
what
she
can
I
mean
the
problem.
Is
it's
actually
unspecified
so
what
she
did
was
proper,
but
mostly
for
hop
limit
because
reads
a
problem
of
the
ipv6
packet.
So
that's
when
it's
kind
of
clear
so
she
recovers
is
the
packets.
Fine
I
would
argue.
F
I
argued
actually
that
she
did
not
need
to
recompose
the
packet,
because
the
hop
limit
is
in
the
first
fragment,
so
she
could
have
sent
the
arrow
back
on
the
first
fragment
with
the
first
fragment
in
and
then
drop
the
next
fragments
and
the
cool
thing
with
that
is
the
arrow
flies
back
to
the
source,
maybe
before
all
the
fragments
are
sent
so
that
the
source
doesn't
waste
bandwidth,
sending
all
the
other
fragments.
So
what
she
did
was
proper.
F
It
was
actually
not
optimized,
but
since
there
is
no
spike
right-
and
it's
not
specific
to
this
fragment
forwarding
draft
so
I
said
I-
don't
see
why
we
should
put
the
text
in
there,
but
that
should
be
working
to
actually
addresses
and
that's
pretty
much.
My
discussions
and
the
drafts
are
in
the
caring
hands
of
Suresh.
D
D
So
now,
let's
take
a
look
at
the
updates
in
this
last
revision.
First
is
after
a
comment
by
Rahul,
we
found
a
few
instances
where
we
were
still
using
a
ro
where,
where,
as
we
should
have
been
using
e,
a
ro,
which
is
the
term
defined
in
RFC,
eighty
five,
zero
five,
this
was
actually
a
couple
of
instances
in
the
header
compression
section.
D
D
Then
there
was
a
third
common,
which
was
mostly
editorial
in
intended
to
express
a
bit
better,
some
sentence.
Hopefully
now
it's
more
readable
and
finally
Rahul
had
also
a
request
to
provide
some
diagram
illustrating
the
node
joining
procedure.
So
we
did
that
we
had
the
appendix
B,
which
now
contains
the
diagram
that
was
requested
and
also
a
text
description
of
what's
happening
in
the
diagram.
So
this
is
a
quite
typical
message.
Exchange
in
this
diagram,
the
the
new
node
is
the
6ln
in
the
figure.
So
basically
the
six
line
starts
sending
router
solicitation
message.
D
So
if
there's
some
node
a
6lr
in
this
case
in
in
range
of
the
new
node,
then
it
will
reply
with
a
router
advertisement.
So
the
new
node
will
be
able
to
configure
its
global
ipv6
address,
because
it
has
now
learned
the
prefix
in
use
and
it
will
register
the
ipv6
global
address
with
each
router.
So
then
there
will
be
the
multi-hop
duplicate
address
detection
procedure
and
finally,
the
6rn
will
receive
the
result
of
this
procedure.
H
G
G
So
in
this
latest
threat
we
have
the
six
six
Road
in
Korea
technology.
She
WAV
barely
there
clearly
be
context
really
MSTP
NFC
PLC.
So
the
last,
the
eighth
ripple
edit,
that
if
that
echo,
our
authors
I
decide
not
to
include
the
SIP
floating
layer
technology.
I
said
in
the
redder
and
this
the
comparison
table
across
six
Road
in
Korea
technology,
so
G
will
be
Billy
death,
usually
MSTP
NFC
piracy,
so
test
Oh
visual
with
restore
d
scg.
G
So
in
the
sixth
row
deployment
scenario,
so
originally
we
have
poor
effect,
occurred
six
row
deep
romantic
scenario
to
fight
image.
Choice
on
this
repair
see
net
Rissa
T.
So
among
them
we
remove
jupyter
mesh
and
white
Sun
because
the
technology
is
based
on
a
triple
area
to
type
in
that
poll.
So
currently
or
two
or
deployment
scenario
such
a
lt3
pearcy.
Yet
riskier
are
remaining
so
we
have
the
Qaeda
line
pod
opting
we
expect,
for
example,
addressing
modere
MTO
consideration,
which
was
reloading,
address,
Oh
Simon,
had
convention
security
and
encryption,
additional
processing,
etc.
G
So
in
the
current
rate
is
trapped.
We
have
to
each
use
case
of
the
86
road
in
clear
technology,
for
example
G
wave
or
it
can
be
used
to
some
at
home,
for
example.
So
really
it
can
be
used
to
can
be
used
to
smartphone,
based
interaction
and,
for
example,
nep-chi
can
be
used
to
authority
of
the
secure
transfer
and
prism
prismatic
good
Piercy
can
be
used
to
smart
grid.
G
Ok,
so
all
this
is
dose
or
summarize
the
command
after
the
last
meeting
and
the
email
discussion
between
all
sorts,
so
I
remember
that
in
the
last
meeting,
maybe
the
escape
documented
this
draft,
but
we
just
caught
the
arrow
down
and
we
must
have
focus
on
something
because
it
is
a
little
too
broad,
so
I
agree
and
I
thanks
to
your
command,
and
we
also
have
some
agreement
today.
So
to
do
this
we
decide.
Ok,
we
must
adjust
the
scope
so
narrow
down
and
pocos.
So
previous
version.
G
They
trapped
in
29
PS
so
currently
is
25
fish
for
fish
reviews
and
we
tried
to
make
consistent
between
each
section
so
email
discussion
paternosters.
So
we
determine
6
rod
technology.
So
we
there
are
some
items
for
regarding
this
repeatable
related
technology,
our
arab
scope,
so
in
the
previous
version,
LT
MP,
she
is
included,
but
we
removed
and
we
try
to
focus
on
technology
that
have
been
handled
after
iris,
original
15
dirt-poor.
G
So
that's
the
reason
we
delete
some
related
parts
of
the
edit
auto
dock
with
Interpol
and
other
technology
which
are
not
related
to
arab
seal
or
working
document.
Arabs.
You
temper,
I,
remember
their
past
car
said
we
have
the
double
lane
aah
threat
in
v6
or
watching
row,
but
it
was
torn
up
to
two
years.
There
are
no
active
activity.
So
this
reason
we
don't
hinder
that
left
in
this
document
here
so
I
did
he
explain
tour
reaction
from
document
from
Pascal?
Okay.
This
is
the
decision.
G
Btw
no
sirs,
so
I
said
that
really
move
later
person.
Who
is
the
editor
to
the
kitchen
table
poor
and
editor
template
Interpol
echo,
so
the
section
or
3.7
4.1
4.2
and
appendix
8
8
v,
imp
river
trip
are
removed,
so
update
able
to
so
in
the
previous
module.
We
used
specified
expression,
but
in
this
opera
we
do
move,
specify
expression
and
we
are
beside
the
606
road
in
cleared
canal
ug
and
we
try
to
reduce
the
content
and
etc.
G
Ok,
all
this
is
the
third
order
flies
to
the
command
prompt.
Ask
our
so
Pascal
suggests
that
it
is
better
to
reverse
the
editor
template
up,
hold
standards
and
include
our
reference.
So
we
do
that
and
Pascal
says
that
pre-birth
disrepair
see
content
is
a
little
out
of
doTERRA,
so
we
check
that
so
I
found
there.
Yes,
it
is
all
little
to
all.
So
we
try
to
catch
the
contest,
features
of
g3p
RC
document
and
Pascal,
or
give
some
text
tour
to
address
assignment.
It
is
a
little,
not
the
proper.
G
For
regarding
to
the
scope
of
this
rep,
though
people,
basically
the
six
role
in
cleared
chronology
to
make
the
score
narrow
down,
we
treat
I
Tripoli
original
pitch
in
the
poor
and
I
deducted
in
the
poor,
echo
and
also
we
delete
six
Road
implemented
scenario,
for
example,
to
fight
a
mesh
and
my
son
so
test
or
resort.
We
have
only
two
six
through
diplomatic
scenario
that
is
based
on
peer
see.
So,
after
dose
of
a
mission,
the
lemme
give
some
top
command.
So
the
first
one
is
related
to
this.
G
So
he
suggests
some
solution
how
to
handle
six
roti
fermentation
REO,
and
let
me
also
suggested
in
the
section
five
for
the
political
base
is
reloading.
It
would
be
better
to
have
equal
tempered
for
material
thing
or
arrow.
Ad
n
diverges
rapira
C,
so
in
the
next
revision,
are
we
or
reflect
this
comment
yet,
or
thank
you
so
I'm
asking
taught
or
and
want
to
hear
your
opinion
to
regarding
of
the
scope
of
this
draft?
G
F
I'm,
just
not
too
clear
what
the
result
of
if
you
declare
the
amount
of
scope
like
I,
think
Jupiter
mesh
is
kind
of
dead
now,
so
it's
kind
of
out
of
scope,
because
it's
not
there
right.
On
the
other
hand,
when
Sun
is
highly
deployed
and
and
lively
and
expertise
in
to
etc,
so
I
guess
it's
interesting
for
the
reader,
at
least
to
know
that
it
exists.
F
Even
if
you
don't
go
into
details
of
what's
being
done
there,
because
I
guess
the
reason
why
it's
out
of
scope-
it's
not
the
main
of
this
another
entity
that
specifies
it,
and
you
can't
really
apart
from
saying
it's
there
and
it
does
high
level
things.
You
can't
go
into
the
detail
of
what
it
does,
because
it's
kind
of
property-
oh
well,
it's
the
ions
right
so
I
would
say
you
still
need
to
say
it
exists
and
used
it's.
F
You
still
need
to
say
it
does
use
this
technology
because
you're
there
to
say
this
technology
is
deployed.
So
it's
important
that
it's
mentioned,
yeah
15,
for
a
the
reason
why
you
are
not
expected
to
talk
too
much
about
it
is
because
now
it
does
not
exist
anymore,
it
is
wrapped
up
into
15
4.
So
when
you
say
15
before,
you
actually
include
th
CH,
because
that's
part
on
the
mains
back
since
2015.
F
So
that's
it's
not
worth
mentioning
it
for
a
reader
of
today
and
because
your
your
reference
is
to
15
for
without
a
date
that
includes
the
SCH
for
anything
college
today.
So
you
don't
need
to
mention,
for
obviously
the
low
pan
in
6lowpan
is
15,
for
so
it's
hard
to
say
15
for
is
out
of
scope.
That
seems
a
bit
harsh
so
and
I'm
not
clear
what
you
mean
by
saying:
15
fives
out
of
scope,
I
think,
but
it
belongs
right.
F
E
Suresh
krisshnan,
I
think
what
they
are
saying
is
like
now.
They
don't
want
to
describe
the
link
layer
technologies
in
the
draft
right.
I.
Think
like
you,
just
a
reference
should
be:
okay,
I,
don't
think
they
want
like
they
want
to
talk
more
about
the
use
cases
of
it
rather
than
the
link
layer,
technology
I.
Think
that's
what
I
understood
from,
but.
E
I
G
I
K
So
I'm
going
to
talk
about
the
ipv6
of
a
PRC
networks,
so
on
some
recall
of
the
background.
The
objective
of
this
draft
is
to
define
ipv6
at
the
adaptation
layer
for
constraint,
PLC's,
and
it
is
based
on
some
already
done.
Ietf
standards
and
some
extensions
to
these
standards
and
the
scope
of
this
draft
is
the
constraint
PLC's,
which
includes
the
itu-t
G,
doubt
99
0-3,
9000,
1.1
and
90
1.2,
and
for
the
status
of
the
draft.
K
He
who
was
started
in
2017
and
it
is
adopted
in
this
year
in
February
and
for
the
version
0
0
we
just
uploaded
eight
eyes
working
of
document
and
with
just
a
simple
change
of
the
title
and
some
ID
row,
modifications
based
on
Carson's
comments
and
in
the
version
0
1.
We
have
done
some
modifications
in
the
structure
and
updates
the
neighbor
discovery
section
and
now
we'll
talk
about
some
modifications.
K
For
now
we
have
removed
the
section
about
extension
as
the
sixth
row
after
adaptation
there.
It
is
we
just
remove
it
for
now
and
because
it
is
the
extension
about
the
about
the
the
comment
frame
header,
it
is
unique
in
it
is
currently
unique
in
the
activity:
G,
dot,
WA
99203
and
in
the
other
two
pieces
in
the
draft.
K
We
just
have
not
use
case
for
for
this
comment
from
a
header
yet,
and
there
is
some
inconsistency,
in
fact,
in
the
order
of
the
common
frame
header
in
2009
9:03,
because
in
this
one,
under
the
Arcia
80
666,
because
in
the
G
dot,
19
and
0-3,
the
command
frame
header
is
the
last
one,
but
in
the
best
definition
of
our
RFC
80-66,
it
is
before
the
the
dispatch
header
of
the
header
compression,
so
insistency
exists.
So
I
I
just
want
to
ask
the
working
groups
opinion.
K
D
K
F
F
I
mean
we
should
have
a
kind
of
a
liaison
question
or
something
right:
I
mean
they
they
did.
They
were
supposed
to
follow
the
RFC
and
to
do
the
thing
as
we
specified
with
this,
we
specified
the
escape
for
them,
and
now
you
say
they
don't
choose
it
as
specified,
and
that
troubles
me
I
think
I
mean
we
cannot
really
you
can
at
the
HF.
You
can
only
be
consistent
with
the
other.
F
K
F
K
F
F
It's
not
much
if
kind
of
normative
reference,
they
should
obey
what
they
RFC
sighs
because
they
say
they
basically
say
we
are
using
the
RFC
and
then
then
they
do
something
which
is
opposite
to
the
RFC.
And
what?
What
do
you
give
the
pound
right,
you're
supposed
to
be
on
up
on
the
RFC
to
do
the
next
RFC
and
so
obviously
I
understand
you
have
a
conflict.
You
cannot
solve
it,
but
the
only
thing
you
can
do
within
this
form-
and
this
group
is
to
be
consistent
with
the
other
RCS.
Okay.
E
Yeah
suresh
krisshnan,
so
just
like
going
a
little
bit
further
like
I,
don't
think
we
can
resolve
this
here:
okay,
okay,
very
frank
right,
because
if
somebody's
gonna
do
something
else
somewhere,
that's
not
much,
we
can
do
about
it.
I
would
say
the
itu-t
needs
to
fix
this.
If
they're
doing
this
in
a
non
inconsistent
way
like
with
our
standards,
it
needs
to
get
fixed
there
right.
Otherwise,
this
draft,
rightly
it's
gonna,
get
stuck
somewhere,
because
if
it's
inconsistent
with
our
RFC's,
it's
not
gonna
progress
right.
E
So,
if
you
want
some
help,
we
can
probably
right
up
a
liaison
statement
and
try
to
find
I.
Don't
know
if
you
have
a
liaison
towards
g19
903
right,
but
we
will
try
to
figure
out
if
we
can
send
a
message
to
them.
Saying
hey
your
usage
of
this
is
inconsistent
with
how
we
specified
it.
That's
something
we
can
do
and
see
how
things
go,
but
if
you
have
any
colleagues
who
are
going
to
itu-t
who
are
working
on
this
like
you
should
talk
to
them
and
tell
them
to
fix
it
over
there.
Okay.
K
E
D
E
Not
fixing
it
there's
not
much,
we
can
do
about
it
and
we
cannot
publish
this
with,
like
obvious
contradiction
to
our
published
standards.
Yeah
yeah,
so
let's
probably
have
an
offline
just
like
we
have
a
shorter
session
today,
so
we
have
a
little
bit
time
left
and
we
can
have
a
chat
about
it.
Okay,.
J
K
Yeah
so
draft.
K
K
K
While
if
the
update
is
to
update
the
RCA
65,
sorry
67
75
update
into
FC
eighty
five
zero
five
and
we
have
divided
the
address
registration
into
two
scene.
Two
situations,
one
is
the
root
over
mode
and
another
way
is
the
measurement
and
in
the
root
over
modes
for
the
link
local
addresses.
They
should
only
be
registered
to
the
to
the
six-hour,
which
is
the
rotor
and
the
folder
known
link.
K
Local
addresses
should
be
registered
to
the
to
the
registrar
and
via
the
neighbor
solicitation
and
the
NEPA
advertisement
and
the
GRDC,
and
if
RFC
3505
is
rotate,
the
EDR
and
the
EDC
messages
are
used
and
the
if
the
address
is
are
signed
by
on
DTV
v6
or
it
has
generated
via
some
unique
link.
Local
link
layer
addresses-
and
in
this
case
the
DoD
must
not
be
utilized
and
the
for
the
machine
remote
each
device
is
link
local
neighbor
at
the
u.s.
rate
to
the
six
fer.
K
So
the
registration,
viralize
and
a
message
is,
should
be
fine,
so
no,
no
dar
DC
or
EDR
EDSA
message,
I
used
in
this
case
and
the
for
the
future
work.
We
think
that
in
the
structure,
a
source
of
the
inconsistency
we
have
mentioned
it,
yet
we
think
that
in
the
for
the
structure
we
I've
covered,
almost
all
the
other
technique
points
for
the
PLC's
so
but
we
need
help
to
help
us
improve
it.
So
any
comments
No.
D
I
I
B
Thank
you,
so
I
will
talk
about
work.
What
is
doing
is
done
at
the
LP
one
working
group,
so
it's
about
compression
and
fragmentation.
So
I
will,
as
I
say,
will
not
talk
much
about
fragmentation,
but
I
will
focus
more
on
compression
and
we
have,
of
course,
things
that
are
common,
because
when
we
start
a
group
we
have
a
good
source
of
inspiration
that
was
six
low
and
off
on
some
offer
a
command
to
the
both
group.
B
So
you
will
find
some
common
things,
but
in
fact
the
applicability
statement
is
totally
different
because
we
are
in
very,
very
constrained
network.
So
here
you
have
some
figure
about
the
speed
of
this
network.
So
some
people
talk
about
milli
bit
networks.
It's,
for
example,
sig
Fox.
If
you
take
the
duty
cycle,
is
one
bit
per
second.
So
it's
a
very,
very
limited
bandwidth,
very,
very
small
frame
and
you
are
limited
in
with
the
number
of
frames
you
can
send
per
day.
So
you
have
a
lot
of
restriction.
B
You
have
also
a
restriction,
for
example,
then
the
device
can
sleep
most
of
the
time.
So
you
cannot
send
darling
message
all
the
time
you
have
to
wait
right,
these
dividers
and
messages,
so
the
constraint
of
the
traffic
is
also
different
at
what
we
you
have
in
6lo
network.
What
is
common
of
all
this
technology
is
that
we
have
a
star
topology,
so
each
device
talk
to
only
one
point
on.
We
don't
have
routing
around,
so
it
means
that
this
way
we
can
also
have
sanitation.
B
So
if
we
look
at
the
architecture,
we
have
a
star
topology
and
we
have
device
that
talks
with
different
by
different
means
to
a
central
point,
and
so,
if
we
want
to
do
compression
and
fragmentation,
we
will
do
it
between
the
device
on
this
central
point.
Here
are
also
one
very
important
assumption
what
we
took
its
ads.
We
know
the
traffic
sent
by
the
device,
because
it's
a
limited
device
and
you
put
your
application
on
it
and
you
can
control
what
as
a
friend
that
has
been
sent
or
received
by
this
application,
so
in
shake.
B
What
we
do
is
that
we
have
a
context
for
compression
decompression,
so
it's
on
the
device,
and
it
must
be
known
also
in
the
core
of
compression
of
the
compressor.
So
the
documents
now
right
now
IT
structure.
So
we
have
one
draft
that
explains
three
things,
so
it's
the
mini,
explain
it
better
than
me,
but
it's
divided
in
three
parts:
the
first
one
describe
a
generic
compression
mechanism,
so
we
don't
say
it
for
UDP
IP.
It
just
fills
and
we
say
how
we
compress
a
packet
made
of
fields.
B
We
have
over
documents,
one
that
explain
how
to
do.
Coop
compression,
so
coop
compression
can
be
done
alone
or
can
be
done
with
UDP
IP
if
needed.
So
we
don't
take
each
layer,
but
we
can
do
cross
cross
layer
compression
and
we
have
also
add
a
adaptation
of
the
ship
mechanism
to
different
technology
like
sig
Foxx
Aloha,
one
3gpp
X
direction
so
how
it
works.
B
In
brief,
you
are
the
package
that
arrived
to
your
compressor,
so
you
have
a
description
of
all
the
possible
format
of
what
you
are
sending
and
when,
if
you
find
something
that
works
that
corresponds,
if
a
rule
that
correspond
to
your
packet,
then
you
will
send
a
rule
number
on
at
the
other
end.
Since
we
have
the
same
information,
then
we
can,
from
the
rule
number
reconstruct
Vader.
So
in
the
vocabulary
of
shake
this
description
of
a
pedra
of
ITER's
is
caller
rule.
It's
identified
by
your
ID.
B
The
set
of
floor
is
color
context
and
for
the
compression,
as
in
6lo,
we
can
have
the
route
ID,
plus
some
information
that
come
from
the
ocean
or
later,
but
we
send
on
on
the
radio.
So
a
rule
is
defined
by
different
element.
So
the
first
thing
to
identify
a
rule
is
that
you
have
a
rule.
Id,
visual
ID
is
absolutely
unstructured,
so
it
does
a
flat
numbering
and
it
can
be
used
to
identify
compression
or
fragmentation.
Work
on
the
size
of
your
ID
may
vary.
B
So
if
you
have
frequent
rules,
they
can
have
a
small
value
and
unfree
controls.
I
have
a
longer
value,
then
a
recompression,
rudy
structure
of
this
way.
You
have
the
first
field
of
the
first
column
of
these
rules
describing
the
field
that
you
are
trying
to
compress.
So
you
have
a
feel
ID
but
say,
for
example,
it's
ipv6
version
or
it's
it's
UDP
port,
Xterra
extra.
You
have
a
field
position,
so
it's
quite
strange.
B
If
you
look
at
IP
UDP,
but
in
coop
for
example,
you
can
repeat
several
time
the
same
field,
either
you're
a
path.
So
we
give
the
position
if
it's
repeated
several
time
on
theater
and
then
we
have
the
direction,
which
is
something
that
is
very
specific
to
LP
ones
network,
because
since
it's
a
star
topology,
we
can
have
uplink
or
downlink
communications.
B
So
we
with
this
information,
we
notified
a
specific
field
and
then
we
have
a
matching
part.
So
the
matching
part
is
with
two
element:
one
is
a
target
value,
so
it's
the
value,
but
you
want
to
too
much
and
we
have
a
matching
operator
that
tells
you
how
to
do
the
matching
with
the
field.
So
we
have
four.
Currently
four
different
definition
are
done.
One
is
equal,
so
you
must
find
this
target
value
in
your
field.
B
Yeah,
ignore
it
mean
that
you
don't
care
about
the
value
you
have
also
MSB,
so
you
have
the
first
bit
must
match
and
a
matching
list.
It
means
that
you
have
a
list
of
value
and
you
expect
to
find
one
of
these
value,
so
our
Sheikh
worth
to
say
walks
to
select
a
rule.
Is
that
all
the
fields
that
are
described
in
the
rule
much
match
with
all
the
field
in
your
packet?
B
If
it's
a
case,
then
you
can
select
the
rule
and
apply
the
compression
action
that
are
described
here,
and
this
way
you
have
gives
you
a
sir
ization
what
you
send
on
your
radio
on
on
the
other
side,
when
you
receive
something
you
receive
first
rule
ID.
So
with
this,
you
can
identify
the
rule,
and
then
you
have
the
residue
that
comes
from
the
compression
that
can
be
can
help
to
reconstruct
the
original
packet
using
a
decompression
action
which
is
symmetric
to
the
compression
action
in
the
component
side.
B
So
that's
in
brief
how
the
compression
works
so
I
try
to
make
some
comparison
between
6lo
behavior
and
shake.
So
we
first
about
the
context.
So
context
is
a
very
difficult
world
because
everybody
has
this
notion
of
context,
but
what
we
can
say
that
in
six
law
we
have
no
state
for
compression
decompression.
It
means
that
you
take
a
packet.
You
apply
what
is
given
in
the
bit
map
at
the
beginning,
and
then
you
forget
this
packet
and
you
go
to
the
next
one.
B
So
every
packet
is
compressed
in
the
individually
and
rules
are
known
by
the
implementation,
because
you
create
your
bitmap
and
you
say:
if
I
have
this
bit
I'm
doing
this
this
this,
and
this
in
shake
is
the
same
thing
about
compression
right.
Now
we
take
a
packet
and
we
do
compression,
and
then
we
forget
about
this
packet
and
we
do
we
go
to
the
compression
another
packet.
So
here
it's
similar.
The
difference
is
that
here,
when
you
receive
a
rule
ID,
you
don't
know
what
to
do.
B
If
you
don't
have
the
rule,
so
the
rule
explain
you
what
will
be
the
behavior
so
in
in
6lo
we
have
a
bitmap
that
can
be
compared
with
a
rule
ID,
but
in
6lo
it's
fixed,
and
it
gives
you
how
you
do
the
compression
as
I
say
before,
shake
the
rule.
Id
is
just
a
pointer
to
a
rule
that
will
tell
you
how
to
do
the
compression.
The
advantage
of
having
no
semantics
is
that
you
can
have
different
lengths
and
you
don't
have
to
structure
this,
this
information
for
compression
and
decompression
action.
B
They
are
also
quite
similar
in
with
6lo,
so
we
have
sent
a
lidded
mapping
and
computed.
They
are
not
exactly
the
same
name,
but
it's
a
what
a
similar
only
shake.
We
have
also
MSB
LSB,
so
it's
in
UDP.
You
can
do
it
in
six
low,
but
it's
not
generic
in
in
shake
and
it
can
be
extensible
extensible.
If
you
want,
you
can
add
new
compression
the
compression
action
so
in
shake
in
six.
No,
it
is
the
RFC
vets
fix
how
you
apply.
B
The
compression
to
ipv6
header
in
shake
is
the
rule
that
defines
of
a
behavior,
and
you
select
one
of
reaction.
So
just
yes,
I
would
like
to
ask
a
question
who
has
read
one
of
the
sheik
draft
right
lot
of
people,
so
we
what
I
think
is
very
variable
from
Sheik,
and
maybe
we
can
work
together
at
six
low
with.
B
That
is
that
we
define
a
generic
field,
compression
mechanism
that
can
be
applied
to
anything
not
only
ipv6
or
our
UDP
and
to
a
lot
of
either,
and
so
maybe
it's
time
now
to
see
how
we
can
work
together,
for
example,
to
a
pride
co-op
compression
over
six
low
or
a
thing
like
this,
so
that
was
presentation
of
what
we
have
done.
So
if
you
have
question
or
comment,
you're
welcome.
K
Remove
from
Hawaii
so
actually
for
me,
Sheik
is
just
like
you
have
a
dictionary
at
both
sides.
Right
indicates
the
number
of
you
and
you
can
do
the
compression
and
decompression.
So
what
do
you
think
in
this
case
is
a
mesh
2/6?
Oh
you
mean
that
we
should
do
some
extensions
in
the
control
plane
to
indicate
the
rule
or
something
like
that,
or
maybe
all
the
other
contacts
here
so
the
in
other
words
the
dictionary,
should
be
pre-installed.
Yes,
this.
B
Is
one
solution?
I
have
no
real
idea
how
to
implement
it.
But
what
is
important
in
Shaykh
is
that
you
have
a
point
to
point
rules.
So
it
means
that,
and
if
you
have
a
rule
number
ten
for
one
Association,
another
rule
number
ten
can
be
totally
different
for
another
Association.
So
it
means
that
you
don't
have
unity
of
rules
number
for
all
your
devices.
B
So
if
we
want
to
apply
in
a
mesh
network,
it
means
that
ever
we
try
to
have
unity
in
lady
or
we
have
to
take
into
account
the
source
and
then
the
rule
number,
and
the
other
thing
is
that
since
we,
the
direction,
for
example,
cannot
be
used
because
in
mesh
there
is
no
up
and
down
so
you
can
receive
in
both
directions.
So
you.
D
Thank
you
for
this
presentation
in
this
work.
I
think
this
is
an
interesting
topic
so
from
some
abstract
point
of
view,
I
agree
that
she
could
be
viewed
as
a
superset
to
some
of
the
functionality
that
is
already
in
6lowpan
header
compression,
for
example,
the
stateless
part
of
sixty
to
eighty,
two
and
I
think
it
makes
sense
to
analyze
this
example
in
6lowpan
header
compression.
D
Typically,
in
the
best
case,
an
IP
UDP
had
ipv6
UDP
compress
header
would
have
a
size
in
the
best
case
of
six
to
seven
bytes,
whereas
with
sheik
it
could
be
easily
one
or
two
bytes,
for
example,
there's
a
trick
which
is
in
cheek
there's
this
information
that
context,
which
is
assumed
to
be
static
like
forever.
Let's
say,
and
basically,
if
you
know
in
advance
how
your
packets
or
packet
headers
will
look
like
you
can
take
advantage
of
that.
B
I
B
They
differ
in
how
extensive
this
context
is
so
in
six
law
we
can
essentially
only
provide
a
few
addresses
that
then
can
be
used
by
the
six
to
eight
compression
mechanism
to
compress
some
some
addresses
a
little
bit
while
shake,
of
course,
has
this
extensive
mechanism
in
shake.
So
far,
the
assumption
has
been
you
provision
this
per
pair
in
sixth
law.
B
The
assumption
has
been
you
provisioned
this
per
network,
or
we
talked
about
area
context
or
whole
6lowpan
shares
the
the
context,
and,
of
course
you
you
can
open
this
up
again
and
and
shake
it
in
quite
different
ways.
So
if
we
did
a
sixth
law
with
prepare
context,
that
would
feel
a
little
bit
different
or
if
we
did
shake
by
distributing
the
information
to
everybody
that
what,
for
you,
are
different
and
so
on
so
I
think
there
are
a
number
of
combinations.
One
can
could
look
into
here
and
it
would
indeed
be
interesting
to
see.
B
Are
there
use
cases
where
these
combinations
actually
make
it
make
sense,
and
if
yes,
what?
What
is
the
level
of
efficiency
that
actually
can
be
achieved,
but
I
think
the
the
main
difference
is
again?
How
do
you
distribute
the
state
who
gets
what
state
and
how
extensive
is
the
set
of
compression
actions
you
actually
can
express
and,
of
course,
in
the
latter
part,
shake
really
is
way
further
than
10
6
long
way.
F
At
scale,
yeah
there's
also
this
concept
of
backward
compatibility,
etc.
So
what
I
just
looked
at
is
how
much
space
we
we
have
in
the
energy
field
of
the
6lowpan
compression,
because
one
way
of
using
shake-
and
you
mentioned
why
son,
when
way
of
using
shake-
is
to
actually
leave
the
other
compression
to
6lowpan,
because
it's
doing
it
and
the
intermediate
nodes
know
what
to
do
about
it
and
we
know
how
to
frog
fragment
and
for
the
fragments
of
our
Monte
harp,
etc.
F
So
could
think
about
leaving
IP
compression
to
6lo
just
for
backward
compatibility
within
your
mesh,
but
upgrade
some
endpoints
to
have
a
new
NHC
next
in
the
compression
for
check.
So,
instead
of
saying,
the
next
error
is
UDP
right,
which
we
do
today
or
you
have
this.
We
don't
really
compress,
there's
a
list,
then
we
could
say.
Oh
there
is
this
other
sort
of
next
data,
which
is
check
and
the
cool
thing
now
is
you
could
transport
shake
for
the
upper
layers
and
still
use
six
low
two
for
the
packet
inside
the
mesh
and.
F
F
Where
has
the
mesh
itself
is
still
six
low
and
I
know
coop,
you
mention
why
Sun
but
for
I
know
the
see
assembly
protocol,
which
is
the
the
coop
simple
measurement
protocol,
is
got,
and
so
so
I
already
see
where
and
how
shake
could
be
useful
for
managing
the
devices
with
with
lower
cost
by
by
using
sheet
to
comprise
the
CMV
messages,
for
instance,
so
I
see
it
very
valuable.
So
that
means
for
six
low.
That's
where
it
becomes
quote
and
quite
interesting
for
us.
F
So
another
advantage
is
effectively
what
I
mean
the
end.
Point
I
really
do
mean
the
end
points
like
the
problem
with.
If
you
use
shake
for
IP,
is
that
you
know
the
first
router
which
goes
to
the
internet
as
to
speak,
shake
because
it
needs
to
decompress
and
it
might
comprise
the
whole
thing,
but
now
with,
if
you
say,
oh
I'm,
using
six
low
pad
for
IP,
it
means
that
I
can
really
reconfigure.
I
can
rebuild
that
six
packet,
where
the
content
is
hidden
within
UDP
to
pass
through
the
firewalls.
F
I
I
M
M
Yeah
so
hello,
I'm,
examiner
and
the
author
of
the
six
low
draft,
and
can
you
switch
your
slide
yeah?
M
Why
do
we
actually
want
to
have
IP
version
6
over
the
canvas
because
IP
version
6
is
technology
in
vendor-independent
we
have
lots
of
application
layer
protocols
like
co-op
and
MQTT
and
whatever
are
UT
protocols
we
have.
Today
we
can
have
transport
layer
security
because
the
campus
is
actually
not
encrypted
and
we
came
in
routing
with
that
and
we
can
have
even
access
to
the
Internet
with
small
devices.
Yes,
which
is
like
this,
but
why
do
we
want
campus
for
the
IP
version
6?
M
The
campus
is
actually
it
has
a
broad
availability
on
small
scale,
MC
use,
for
example,
HP
times
use
and
also
a
large
scale
like
quarter
the
army
application
processes,
it
is
very
cheap.
Actually
it
is
a
very
small
hardware
footprint.
It
does
not
vary
just
small
components.
In
addition,
you
need
to
the
controller
it's
a
very
robust
bus.
It
has
a
simple
wiring
and
it's
actually
widely
used.
Even
though
we
see
it,
we
don't
see
it
today.
Can
you
go
to
the
next
slide?
M
One
before
there
was
one
in
between
yeah,
the
campus
is
a
multi
master
bus,
so
we
have
multiple
slaves
connected
in
parallel
to
together
it
has
a
line
Technol
line
topology.
It
is
a
two
wire
bus
and
we
can
have
up
to
one
Meg
about
speed
and
for
the
new
version
with
the
flexible
data
rate
we
can
have
up
to
it
make
about,
but
that
heavily
depends
on
the
path
length.
The
next
slide
please.
M
This
is
what
a
current
frame
looks
like.
We
have
either
11
bit
or
29
bit
identifier,
but
those
identifiers
are
not
noted
verses,
but
they
identify
frames.
We
have
up
to
8
bytes
of
payload
in
classical,
can
and
64
bytes
payloads
for
the
flexible
data
rates
frames,
but
for
IP
version
6
we
need
note
addresses
it
was
ok,
please
next
slide
for
IP
version
6,
we
need
notices.
So
the
draft
creates
a
node
address
which
is
40
bits
wide.
M
It
can
either
be
randomly
assigned
or
statically
assigned
to
the
nodes,
but
it
must
be
unique
on
the
bus
next
slide,
please.
But
how
do
we
map
those
nodes
identifiers
to
the
identifiers
of
the
canvas
which
has
stitched
em
together?
So
in
the
in
the
higher
14
bits
we
have
the
destination
address
in
the
lower
40
bits
worth
2
source
address
and
the
most
highest
bit
is
a
multicast
ik.
The
next
type
is
for
multicast,
which
has
set
the
multicast
flag
to
1
and
then
the
destination
address
changes
to
the
multicast
group.
M
M
The
remote
transmission
requests
is
sent
out
with
the
tentative
address
we
want
as
destination
address
and
some
entropy
in
source,
and
then
we
rate
at
least
400
milliseconds
for
response
on
the
special
address
we
can
see
here
this
libraries
TDI
D
address
and
if
the
source
address
is
the
tentative
address
and
we
get
a
message.
We
know
that
this
this
address
is
already
used
and
if
you
don't
get
a
message,
we
can
guarantee
that
it's
unique
on
the
bus
and
next
slide.
Please,
because
we
only
have
8
bytes
of
payload
or
64.
M
We
need
some
fragmentation
and
reassembly,
because
the
minimal
MTO,
as
we
all
know,
is
1280
bytes,
but
the
six
low
fragmentation
is
2
by
K.
The
6
low
fragmentation
would
already
need
about
the
half
of
the
payload
for
every
frame,
so
I
used
a
matter
fragmentation
and
reassembly
protocol,
which
is
specified
in
an
iso
standard.
It's
the
iso
TP
protocol.
It
provides
us
fragmentation
and
reassembly
and
it
also
has
flow
control,
but
only
for
unique
hosts
next
slide.
Please.
M
We
also
use
the
6
low,
IP
header
compression,
because
after
a
big
IP
header
for
40
bytes,
this
would
take
6
can
frames
and
with
the
compression,
if
you're
lucky,
we
can
go
down
to
3
frames
next
slide.
Please.
We
also
introduced
the
border
translator.
This
border
translator
translates
the
traffic
on
the
canvas
to
the
Ethernet,
so
it
does
the
reassembling
of
the
after
frames
and
then
it
extends
the
addresses
from
load
ultras
to
make
addresses
and
forwards
them
to
the
Ethernet.
M
So
the
translation
is
on
the
link,
layer
and
devices
behind
the
Ethernet
are,
or
there
are
also
in
the
link
level
in
the
link
local
domain.
Next,
like
this,
we
have
all
the
reference
implementation.
The
6
low
count
is
already
implemented
in
the
sefar
artists
and
it's
there
since
version
2
in
the
mainline
tree.
There
are
examples
to
test
yeah,
that's
okay,
that
so
are
there
any
questions.
I.
I
G
J
Hello
commonly
from
Hawaii
today
I
will
talk
about
a
symmetric
ipv6.
This
is
the
second
time
we
presented
these
drafts
here
gives
ok
were
simple
remainder.
There
are,
there
are
many
steps
in
a
symmetric
ipv6
so
for
the
first
one
is
defense.
Address
lanes,
end
is
in
your
domain
and
second,
we
will.
We
will
use
our
dresses
in
self
domain.
It
have
a
common
prefix
with
the
lens
of
some
bits.
The
bits
lanes
echoed
128
minus
N,
and
it's
in
we
will
route
on
the
shorten
the
glasses
and
mow
or
we
can.
J
Okay,
just
it's
a
simple
simple
example:
the
first
step
of
this
are
including
piece,
including
the
flexible
header,
including
octet,
and
is
a
modified
of
ocean
fields
and
tinned
normal
ipv6
ipv6
fields,
but
path
often
can
be
alighted
when
needed,
so
multiple
it
in
the
draft.
So
you
can
reduce
the
draft
and
maybe
have
some
comments
or
question
okay.
J
J
That
means,
after
context,
is
it
established
the
fields
to
be
compressed
to
not
change
and
but
as
a
magical,
ipv6
offers
dynamic
controls
of
the
fields
to
be
compressed
because
the
cooling
bees
are
included
in
every
package,
so
in
a
symmetric
solutions,
the
short
and
the
long
addresses
can
be
used
in
the
same
package.
J
So
we
used
the
bitmap
and
The
Dispatch
and
it
back
together.
So
it's
a
combination
of
often
and
I
read
I!
Really
you
are
draft
about
your
draft,
so
it
may
it
may
it
may
be
equivalent
to
a
rua
t,
but
but
we
think
we
should
specify
the
concrete
rules
for
the
zip
for
the
simplest
device.
Implementation.
D
So
one
one
question
would
be
that
in
the
new
version
of
the
document
there's
the
section
which
compares
your
solution
with
Sheikh,
however
I,
perhaps
I
hope
I
haven't
missed
it.
I
didn't
find
a
comparison
with
existing
6lowpan
or
6lo
header
compression.
So
how
would
your
solution
compared
with
the
existing
one
in
6006
open?
Yes,.
J
J
So
I
have
a
question
for
chairs
to
do.
Six
low
needs
draft
of
how
to
defines
how
to
defend
the
compression
of
ipv6
graphs
in.
J
I
Can
we
ask
you
to
add
a
section
on
advantages
of
this
over
the
existing
six
load,
similar
to
what
you
have
done,
the
comparison
on
she?
Could
you
add
the
advantages
of
this
or
where
this
makes
sense
over
the
existing
six
low
header
compression,
and
then
we
will
get
it
reviewed
from
the
workgroup
and
see
how
to
progress.
I
D
F
F
Just
wondered
for
the
ipv6
of
our
chicken
I
thought
I'm.
So
over
can
six
little
can
think.
I
was
just
curious
if
shake
was
considered,
because
it
makes
so
much
sense
to
use
shake
their
so
I
mean
before
we
go
deep
into
oh
the
bits
of
six
logos
this
way
or
this
way
there
is
one
problem
this
which
needs
to
be
addressed.
F
M
F
D
D
That
I
think
that
considering
well
from
the
ITF
we
we
have
from
the
LP
one
working
group,
the
Sheik
fragmentation,
which
you
might
want
to
look
at
to
see
whether
it
might
also
fulfill
your
requirements
here.
It's
also
able
to
perform
fragmentation
with
flow
control
and
fragment
recovery.
There
are
different
flavors
there
and
also
it's
it's
been
designed
for
they
know
just
where
the
MT
is
really
really
low,
really
small.
So
perhaps
it's
something
in
the
lines
of
what.