►
From YouTube: IETF112-6LO-20211108-1430
Description
6LO meeting session at IETF112
2021/11/08 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
A
A
A
Then
we
have
two
documents
that
have
been
evaluated
by
the
isd.
The
first
is
ipv6
over
nfc
and
this
document
was
elevated,
the
first
time
by
the
asg
a
couple
of
years
ago.
Then
it
was
updated
after
some
time
and
in
the
last
eight
years
there
was
some
some
conversation
about
whether
the
nfc
specification
would
be
available
to
all
the
intended
participants.
B
I
went
through
some
stuff
that
was
publicly
available,
but
I
think
the
broader
concern
that
the
isg
chair
had
was
basically
how
do
we
communicate
that
everybody
who
needed
to
read
the
details
of
the
spec
was
able
to
read
the
details
of
the
spec
when
the
working
group
was
was
drafting
the
document
or
what
it
was
in
last
call
I
it
might
suffice
to
just
have
a
reference
to
bcp,
97
or
best
or
something
in
in
the
shepherd
write-up
or
I
don't.
I
don't
know.
A
So,
okay,
okay,
thank
you,
then.
The
next
document
that
has
been
emulated
by
the
isd
more
recently
is
ibvc
adobe
plc.
So
there
are
at
the
moment
three
outstanding
discuss
ballots
and
there
were
several
comments.
The
authors
have
a
plan
to
submit
the
revised
version
of
the
draft
in
roughly
two
weeks
and
at
the
moment
have
already
replied
to
most
of
the
comments.
A
Then
the
next
document
is
six
low
use
cases
draft
which
passed
the
second
working
group
last
call,
so
the
next
step
will
be
getting
the
shepherd
write
up
and
finally,
we
have
a
new
working
group
document
entitled
ipv6
multicast
address.
This
is
a
registration
which
was
adopted
very
recently
and
which
had
pretty
good
support
and
by
the
way
this
will
be
presented
later
today.
C
C
C
C
Initially,
the
the
focus
was
on
wireless,
so
it
at
some
point.
We
called
it
wind
for
wireless
nd,
but
now
we
are
proposing
it
for
rift.
We
are
proposing
it
for
a
vpn,
so
it's
it's
way
beyond
wireless
and
wireless
does
not,
and
wireless
in
the
title
does
not
really
help
understand
what
this
is.
So
recently,
it's
been
proposed
to
to
call
this
family
of
protocols.
C
When
you
have
a
network
where
you
have
legacy
and
d
a
and
eight
five
four
five
which
coexist
and
the
most
classical
example,
being
eight
five,
four
five
on
the
wireless
and
eight
nine
to
nine
on
the
wire,
but
it
can
be
any
other
composition
of
network,
and
now
we
have.
We
have
two
new
documents
which
are
being
proposed
to
this
group.
One
is
still
personal
submission
I
will
discuss
it
next
and
the
one
that
we
are
talking
about
now
is
is
the
multicast
registration.
C
So,
as
you
know,
h505
was
about
unicast
ipv6
addresses,
and
so
you
could
not
register
multicast,
and
if
you
did
register
any
cash
there
was
no
signaling
to
say
hey.
I
may
I
might
not
be
the
only
one
who
wants
this
address
and
this
could
create
confusion
in
the
routing
and
only
one
node
could
possibly
win
and
that
prevents
the
use
of
any
cast
followed,
balancing
purpose,
for
instance.
C
The
benefit
is
that
the
6lm
goes
mostly
unmodified.
I
mean
all
it
needs
to
know
is
yes,
I
will
accept
packets
for
those
anycast
and
multicast
addresses,
as
I
would
accept
packets
for
my
anycast
addresses,
and
I
won't
use
them
as
source.
That's
pretty
much,
you
know
all
it
needs
to
know,
and
we
we
validate,
that.
C
It
knows
that
because,
when
it
registers
a
multicast
on
any
cast
address,
now,
there's
a
new
flag
associated
in
the
ero
and
actually
in
the
idaho
message
as
well
to
to
to
signal
the
addresses,
unique
unicast
any
cast
or
multicast
there's
more
work
on
the
6lr
side.
Because
now
it
will
accept
more
than
one
registration
for
the
same
address
and
so
for
any
cast
and
multicast
address.
The
index
for
the
registration
becomes.
C
So
we
kind
of
decided
to
make
a
a
unique,
consistent
operation
between
what
six
lapel
does
on
on
the
6ln
to
6lr
hub
and
what
triple
will
do
on
the
rest
of
the
network.
So
we
also
specify
the
ripple
piece
and
for
that
we
extend
rfc
6550,
in
particular
with
a
new
map
mode
of
operations.
For
for
those
familiar
with
ripple,
a
ripple
has
number
of
modes
of
operation.
C
Actually,
I'm
sorry
mob.
Five,
oh
well,
not
for
our
map.
Five,
we
hope
is
mark
four,
because
mob4
was
just
an
experimental
rfc
so
far,
and
if
that's
more,
for
that
means
that
we
frame
up
five
for
for
the
new
non-storing
multicast
mode,
that
this
specification
is
introducing
and
for
any
cast
there
was
strictly
nothing
all
we
set
for
any
cast
is.
If
you
inject
the
same,
addresses
at
multiple
places
network,
you
should
use
the
same
sequence
counter.
C
C
So
this
this
tells
you
a
little
bit
more
on
the
new
ripple
map,
we'll
discuss
more
the
the
the
ripple
side
at
the
roll
meeting.
So
if
you're
interested
in
this
document
and
this
multicast
operation
for
lln,
I
invite
you
to
also
attend
the
role
discussion
later
on
this
week.
I
think
it's
wednesday,
so
the
six
sellers,
as
I
said
earlier,
they
they
have
a
little
bit
more
to
do.
First,
they
need
to
accept
more
than
one
registration
with
different
rovers
and
they
they
will
not
consider
them
as
duplicate.
C
They
have
to
pass
the
new
flags
saying
unicast,
multicast
versus
anycast
in
in
the
arrow,
and
turn
that
into
dao
in
the
the
ripple
target
option.
Now
we
have
the
same
flags
for
any
caster
multicast
which
which
has
to
have
to
be
set
and
as
the
6lr
injects,
that
into
ripple
in
with
the
new
mode
of
operation.
C
The
dow
from
the
6lr
flows
all
the
way
to
the
root,
just
as
if
it
was
an
external
destination,
a
ripple
and
a
wildlife,
and
so
the
multicast
or
any
gas
packet
back
can
be
tunneled
to
the
6lr,
with
exactly
the
same
tunnel
as
if
it
was
a
unicast
packet
to
ripple
a
neural
leaf.
The
the
six
large
encapsulates
that
packet
and
instead
of
a
unicast
ip
packet,
it
will
find
any
cast
on
multicast.
Then
it
will
rot
them
appropriately
to
the
600
packets,
which
are
generated
inside
the
deardag.
C
C
If
it
is
multicast,
it
will
perform
ingress
replication,
meaning
that
it
will
make
one
copy
per
6lr,
which
has
listener
at
least
one
listener.
For
for
that
multicast,
so
a
number
of
the
six
lr's
will
will
get
a
packet
over
their
tunnel
and
encapsulate
and
forward
to
their
six
senates
each
6lr
registers.
Only
once
I
mean
it
just
injects
one
in
in
ripple,
meaning
that
the
root
will
will
have
to
distribute
one
packet
per
6lr
and
it's
the
sixth
error
role
to
distribute
multiple
copies
to
the
six
elements
for
any
cast.
C
Instead
of
passing
the
packet
to
all
the
six
errors,
it
will
pass
it
to
a
select
one
and
we
don't
effectively
say
in
this
specification,
which
xlr
I
mean.
The
policy
in
the
root
may
depend
on
the
number
of
things
like
load,
and
this
specification
does
not
enter
this
configuration
just
says:
the
root
can
select
one
and
further
specification
or
implementation
will
decide
which
one
next
slide.
Please.
C
Actually,
the
6lbr
is
modified
in
the
exact
same
fashion
and,
as
we
extend
the
arrow
to
add
the
a
for
any
cast
and
m
for
multicast
flags.
We
also
change
the
idah
message
to
to
carry
those
flags
and
by
the
way
we
do
that
using
the
status
field,
which
is
the
only
field
that
was
still
free
in
the
other
message
and
which
was
used
for
the
edac
the
confirm,
but
not
for
the
idaho
request.
So
now
for
the
ida
request,
we
set
the
flags
in
the
same
byte.
C
We
actually
in
indicate
extend
that
mode
to
to
say
that
the
flag
must
be
set
for
multicast
if
it's
multicast
or
any
gas.
If
it's
any
cast
and
for
any
case
we,
we
specifically
indicate
what
the
new
behavior
is,
which
is
you
select
one
of
those
children
and
only
one
for
multicast.
You
basically
make
a
copy
per
child
in
storing
mode.
C
On
the
way
back
when
the
the
packet
is
received
from
from
the
parent
in
storing
mode
and
from
the
root
in
non-storing
mode,
the
6r,
the
capsulative
tunnel,
looks
at
the
packet,
and
now
it
can
be
any
cast
on
multicast.
So
it
will
find
possibly
more
than
one
registration.
If
it's
any
cast,
it
will
select.
C
One
again,
we
don't
say
by
which
logic
which
policy
and
the
only
thing
is,
if
the
the
back,
if
it
doesn't
manage
to
send
that
packet
to
that
selected
6ln,
he
still
has
the
opportunity
to
select
another
6ln
which
listens
to
the
same
anycast
address
and
after
some
retries
retry
to
this
other
six
element
for
multicast.
The
goal
is
to
deliver
one
copy
to
each
child
and
in
radio
networks,
radio
lens.
Typically
it's
it
is
more
reliable
to
do
a
unicast
replication.
C
C
So,
there's
a
lot
of
consideration
about
backward
compatibility.
This
document,
this
specification
was
done
by
the
explicit
request
of
ysan,
which
is
one
of
the
alliance
which
used
six
six
law
specifications
and
they
were
effectively
in
need
of
having
a
support
for
multicast
and
they
needed
the
spec
from
the
iatf
to
cover
it.
They
were.
You
know,
very
pleased
that
we
propose
something
that
does
not
entail
supporting
mld
and
so,
as
is
the
fact,
the
case
with
h505,
even
for
multicast.
C
Now
the
device
can
live
without
any
mld
at
all.
But
but
there
is
a
lot
of
of
brownfield
there's
a
lot
of
deployments
of
this
alien
specification
that
will
need
to
be
incrementally
improved
by
with
the
part
of
multicast.
So
there
needs
to
be
compatibility
and
deployment
considerations
regarding
mode
of
operation,
one
in
particular
which
which
is
deployed
throughout.
C
C
C
We
are
also
providing
already
some
other
integrations
in
in
this
specification,
and
we
discussed
in
particular
the
use
of
meeple,
which
is
also
quite
used
in
lln,
so
we
basically
say
hey.
You
can
use
the
new
mod
of
operation
for
non-storing
multicast,
even
if
the
the
routing
for
multicast
is
not
triple.
It's
not
disingress
replication
by
the
root.
Instead
of
doing
this
ingress
replication,
you
can,
for
instance,
use
meepo
to
to
us.
C
You
know
it's
a
flooding
mechanism
to
flood
the
multicast
message
and
then
the
6lrs
will
get
their
copy
and
they
will
do
as
if
it
was
received
out
of
the
tunnel
voila
so
yeah.
This
is
a
very
recent
document.
We
are
actually
trying
to
work
very
very
swiftly
on
this
one
because
of
this
external
alliance,
which
which
needs
it.
You
know
as
soon
as
we
can
deliver
it,
so
we
are
proving
actually
that
the
itf
can
deliver
respect
in
in
a
fast
space
when
that's
really
needed
by
by
our
partners.
C
A
C
C
There
will
be
definitely
a
sharing
with
raw,
because
I'm
presenting
at
role
and
at
some
point
we
will
have
to
ask
our
id
to
to
synchronize
with
alvaro
retina
with
the
routing
id
in
charge
of
of
raw
to
to
figure
out
how
we
progress
this
document.
The
the
idea
was
so
far
that
we
we
progressed
at
six
low
and
but
we
must
have
reviews
by
wrong,
and
so
at
some
point
I
guess
there
will
be
maybe
a
last
call
or
something
at
all
as
well.
C
C
C
There
is
this
knowledge
of
at
least
the
partial
knowledge
of
the
address
mapping
for
at
least
some
of
the
addresses
mapping
of
mac
and
ip
address,
which
can
be
used
to
reply
to
an
ns
lookup
for
all
the
addresses
which
are
registered
to
the
6
lbr.
The
6lbr
could
definitely
answer
as
a
unicast
request
response
exchange
to
an
address
lookup,
as
opposed
to
doing
the
the
multicast
ns
lookup
that
you
all
know
ends
up
as
a
broadcast
on
your
system.
C
So,
yes,
it
only
works
if
the
address
is
registered.
Otherwise
you
know
basically
the
6lbr
needs
to
say
hey.
I
don't
have
this
registration,
so
if
you
have
any
other
way,
but
at
least
it
can
be
tried
as
a
quick
first
try
before
the
the
lookup,
the
actual
lookup
is
done.
You
might
realize
that
the
6lbr
is
is
really
abstract.
C
C
On
the
other
hand,
it
can
be
implemented
as
a
lisp
map
server
map,
requester
msmr,
in
which
case
it's
you
know
it
appears
as
centralized,
even
if
just
like
dns
it
can
be
something
complex
in
the
back
end.
So
the
6lbr
is
really
a
conceptual
object.
What
we
do
with
those
rfcs
is,
we
just
provide
a
handy
type
of
messaging
to
talk
to
the
6mbr
and
so
far
it
was
used
mostly
to
to
provide
duplicate,
address
detection.
That
was
the
goal
in
the
original
rfc
6775
of
a
whiteboard.
C
Well,
we
can
write
all
the
existing
addresses.
So
if
there
is
a
duplication,
we
can
see
it
from
that
board
without
doing
broadcast.
Well
with
the
draft
that
we
are
talking
about
now,
we
are
also
enhancing
the
6lbr
as
being
the
a
registrar
that
you
can
query
for
address
lookup
and
when
that
works.
Well,
you
have
a
very
fast
and
unicast.
C
What's
the
mapping
is
pretty
much
asking
your
router,
which
does
the
vpn
what's
the
mapping,
because
he
has
that
information
in
the
in
the
case
of
vpn
it
will.
The
router
will
use
it
itself
to
encapsulate
in
the
vxlan,
but
actually
you
could
consider
a
very
same
fabric
while
you
don't
effectively
encapsulate
you
just
ask
the
router
hey,
give
me
this
mapping.
I
will
use
it
right
away
on
the
flat
fabric
next
slide.
Please.
C
So
this
is,
like
I
said,
a
very
old
draft
which
was
published.
You
know
when
we,
we
kind
of
were
finishing
the
background
router
document
and
we
just
realized
hey
instead
of
having
six
lbrs
all
across
the
networks
in,
for
instance,
within
the
wi-fi
access
points,
you
could
actually
consider
it
as
more
abstract
and
centralized
on
somewhere
on
the
backbone.
C
And
if
you
do
that,
then
then
anybody
can
query
it
and
that's
pretty
much
what
this
document
is
doing
to
be
able
to
query
it.
We
needed
the
sla
option
in
the
edit
message,
because
that's
usually
how
the
cxlr,
which
would
be
all
the
access
points,
are
talking
to
the
six
lvr,
which
is
which
is
now
centralized,
virtually
centralized
and
and
that
that
that
addition
was
already
done
with
eight
nine
to
nine.
So
we
don't
even
need
to
specify
it.
C
Eight
nine
two
nine
already
said:
hey,
you
can
transport
your
nd
options
in
the
other
message.
So
now
we
are
we.
We
are
actually
leveraging
that,
because
the
through
the
diary
dac
or
through
the
nsna
exchange,
the
6lbr
will
be
aware
of
the
mapping,
and
you
can
query
it
either.
On
the
local
link,
using
an
sna
or
even
from
remote,
using
either
idac
to
to
get
the
address
mappings,
so
we
we
started
the
draft
at
sixth
low
two
years
ago.
C
There
was
this
comment
that
it's
it's
mostly
for
the
ethernet
side,
so
maybe
you
could
try
six
man,
so
one
to
six
men
tried
and
failed
to
to
raise
interest
and
that
that
can
be
explained
by
the
fact
that
we
are
not
maintaining
an
existing
protocol
which
is
really
the
specialty
or
that
group.
But
we
are
creating
really
something
new
which
is
based
on
work,
which
was
done
elsewhere,
and
so
I
mean
we
never
really
caught
up
at
six
men
with
any
of
this
work.
C
C
C
And
by
the
way
we
we
we
provide
this
new
message
which
is
similar
to
a
dac,
but
the
code,
the
the
the
type
is
the
same
as
in
the
redac,
but
the
code
is
is
incriminate
to
say
instead
of
saying
address.
Duplication,
remember,
redac
is,
is
duplication,
bad.
Basically,
this
becomes
address
mapping.
So
it's
it's
got
one
instance
of
godzilla
called
prefix
one
and
it
really
means
address
mapping,
so
you
can
use
it
to
query
and
address
mapping
and
get
a
response
back
and
that's
it
this
time.
Shredder.
C
D
A
A
So,
first
of
all,
as
a
quick
reminder
of
the
motivation
for
this
draft,
as
the
working
group
knows,
rfc62a2
has
been
the
basis
for
header
compression
in
six
low
pan
and
also
in
six
law.
It
was
designed
for
15.4
the
target
technology
below
ipv6
and
it
has
been
adapted
or
reused
several
times
for
the
relatively
similar
iot
technologies,
for
which
ipv6
support
has
been
enabled
and
well
last
year
there
was
the
publication
of
rfc
8724,
also
known
as
chic,
which
is
a
product
of
the
lp1
working
group.
A
She
defines
adaptation
layer,
functionality
and
it
includes
a
header
compression
component,
so
she
has
been
designed
for
even
more
constrained
technologies
which
are
such
as
lp1
technologies,
and
for
that
the
header
compression
in
chic
is
more
aggressive
than
the
one
in
insecure
pan.
The
trick
is
using
static
context
based
on
a
priori
knowledge
of
head
field
values.
A
A
A
A
A
A
There
are
two
terms
which
are
related
with
the
underlying
architecture:
that's
assumed
where
there
will
be
devices
like,
for
example,
sensors,
here
abbreviated
as
depth
and
some
application,
which
might
correspond
to
some
entity
in
charge
of
centralizing
data
collection
on
the
network
side.
Here
abbreviated
as
app.
A
These
two
terms
allow
to
use
a
single
rule
in
both
directions.
So
there's
no
need
to
have
one
rule
for
compressing
when
we
send
in
one
direction
another
rule
for
the
other
direction.
However,
the
problem
here
is
that
in
15.4
networks,
these
two
concepts
do
not
always
apply.
For
example,
when
the
two
endpoints
that
are
communicating
are
in
a
mesh
network
and
are
in
the
same
category.
A
Instead,
we
use
compute
iid
and
then
there's
another
consequence,
which
is
that
in
the
base
chic
specification,
the
terms
uplink
and
downlink
are
defined
by
using
that
an
app.
So
if
devenup
do
not
always
apply
the
same
happens
with
applying
and
downlink,
so
perhaps
we
may
want
to
use
new
terms
the
list
in
some
cases
which
could
be
transmit
and
receive,
as
is
in
version
zero
one
in
this
document.
E
A
E
A
Well,
admittedly,
this
is
a
bit
tentative,
so
yeah,
it
seems
like
at
least
for
the
use
cases
that
we
were
considering
it
bit
seemed
to
be
suitable,
seem
to
be
enough,
although
this
is
actually
open
to
to
discussion.
So
if
there
is
feedback
on
these
or
some
alternative
ideas,
we
are
open
to
to
discuss
this.
E
A
C
Yes,
I
was
wondering
yes
this
this
point
that
you
made
about
device
two
device.
Basically,
when
you
I
mean
I'm
a
bit
anxious
about
this
deriving
from
iid
and-
and
it
doesn't
seem
too
fair
to
to
find
out
that
you
need
to
to
operate
in
in
a
mode
symmetrical
or
non-symmetrical,
based
on
the
trust,
I'm
still
a
bit
confused
by
that.
I
hope
we
can
discuss
and
find
something
a
bit
different,
but
the
the
core
of
my
question
is:
is
the
lp1
architecture.
C
We
are
writing
in
this
architecture
that
you
have
both
cases
effectively,
as
you
described
the
the
asymmetrical
and
the
symmetrical
kind
of
modes,
and
I
just
wanted
to
make
sure
that
that
what
you
are
presenting
here
is
completely
covered
by
the
architecture.
Otherwise,
we
probably
need
to
to
adapt
the
architecture
to
make
sure
that
what
you
describe
what
you
need
is
is
also
there.
C
So
so,
yes,
basically,
I
was
asking
hey:
can
we
sync
this
document
and
the
architecture
make
sure
we
have
the
full
story,
and
this
story
of
iid
doesn't
look
fair,
okay,
okay,
yeah
I
mean.
If,
if
you
were
talking
about
bluetooth,
we
could
say
hey
kind
of
easy
right.
If
you
talk
to
to
the
central
device,
then
probably
you
can
be
asymmetric
or
if
you
talk
device
to
device
you
would
be
symmetrical
because
you
know
who
is
your
central
device,
but
in
154
you
don't
know
who
would
that
be?
C
D
F
F
Okay,
thank
you.
I'm
gonna
present
in
the
next
two
minutes.
Also,
an
update
about
the
native
short
address
draft
so
slide
next
yeah.
Thank
you.
Also.
There
are
a
few
things
that
are
new
in
this
document,
including
me
as
a
co-author.
I'm
not
the
only
one
that
joined
the
the
effort.
That
is
also
david
pegley
of
china
mobile
one
important
thing
is
the
fact
that
actually,
the
the
document
changed
name.
So
this
is
a
revision
actually,
but
still
numbered
0-0.
F
Okay
and
we,
we
also
spent
some
quite
some
effort
in
try
to
detail
the
scope
of
the
document,
because
this
is,
as
I
said,
is
about
lln,
but
with
fixed
geolocations.
So
the
the
kind
of
mobility
that
we
can
have
in
this
kind
of
networks
is
mostly
related
to
radio
connectivity,
not
physical
mobility.
Okay,
next.
F
Okay,
for
those
who
knows
the
the
content
of
the
the
previous
version,
there
is
one
section
which
is
the
nsa
allocation,
so
basically
how
we
create
the
addressing
of
the
different
nodes,
so
the
the
allocation
function,
that
does
that
specific
action
has
been
better
formalized.
So
that
is
a
little
bit
clearer
to
understand
and,
most
importantly,
we
added
a
step-by-step
example,
so
that
we
really
can
see
how
to
build
the
addressing
and
how
it
works.
F
Yet,
at
the
same
time,
the
allocation
function
is
open
to
be
modified.
If
someone
wants
to
okay,
if
by
any
reason
it
finds
something
that
allows
you
to
improve
one
aspect
of
the
other,
the
the
specs
now
allowed
to,
let's
say,
upgrade
the
allocation
function,
and
we
also
added
further
clarification
about
the
nsa
addresses
itself,
how
they
interact
with
ipv6
and
how
the
what
happened,
what
happens
with
the
whis
of
the
routing
tree,
depending
on
the
topology
that
we
have
slide.
F
We
refined
also
the
description
of
the
erotic
mechanism
because,
depending
on
how
the
how
the
the
addressing
allocation
is
done,
then
we
have
actually
a
very
simple
way
to
do
the
forwarding,
because
we
basically
look
at
the
length
of
the
address
and
we
take
a
decision.
So
if
the
the
address
is
shorter,
it
means
I
I
have
to
send
it
up
in
in
the
in
the
hierarchy
of
the
tree
that
we
we
are
building.
F
If
it
is
the
same
length,
I
ask
I'm
the
destination
yes
or
not.
If
not,
I
send
upwards
of
if
it
that
the
destination
has
a
longer
addresses
and
this
in
the
prefix
of
a
certain
node.
He
sends
it
downwards.
Let's
say
so:
we
we
better
clarified
everything
every
step
and
we
added
a
flowchart
that
hopefully
helps
in
understanding
what
all
these
operations
next.
F
We
revised
a
little
bit
the
communication
with
an
external
nodes,
so
when
we
go
beyond
the
root
of
the
nsa
is
building
and
we
want
to
communicate
with
the
ipv6
destination.
Basically,
so
there
is
an
important
distinction
to
be
done.
One
is
when
someone
external
wants
to
contact
a
certain
node
so,
but
by
in
that
case,
it
is
easy
to
to
set
up
the
communication,
because
at
the
very
end,
is
the
route
that
decides
a
mapping
between
the
external
ipv6
address
and
a
an
artificial
nsa
address
that
is
used
to
map
with
the
externa.
F
F
We
try
to
polish
also
or
simplify
the
the
various
figures
that
are
there,
and
I
better
highlight
the
benefits
that
the
nsa
format
introduces.
The
ayanna
section
has
been
completely
revised.
I
mean
this
is
in
line
with
how
the
the
ayanna
consideration
section
should
be
written.
So
we
are
asking
for
the
some
registry
and
we
start
to
populate
the
content
of
those.
D
F
F
So
this
is
the
the
final
slide.
We,
we
did
quite
a
thorough
work
and
we
are
going
forward,
so
the
last
slide
was
about.
We,
the
authors,
think
that
the
the
the
the
document
is
stable
and
maybe
it
could
be
considered
to
be
adopted
as
a
working
group
item
yes
to
be
discussed,
I
don't
know
if
we
have
time
now,
but
certainly
maybe
later
on
the
mailing
list.
A
Yeah,
so
perhaps
there's
not
much
time,
but
there
was
one
point
that
raised
some
concerns
in
the
previous
presentation
in
the
last
idea
about
the
renumbering
and
so
on.
When
there
was
this
dynamic
in
the
network
with
links
changing
and
so
on.
So
it
would
be
good
to
to
see
whether
the
people
who
had
concerns
on
this
may
have
any
comments
so
yeah.
Perhaps
it
will
be
good
to
have
some
discussion
on
the
mailing
list
about
whether
the
updates
address
those
concerns.
F
Yeah
we
proposed
a
solution.
We
certainly
can
discuss
more
on
the
mailing
list,
knowing
that
we
we
consider
a
rather
static
scenario,
but
but
anyway,
absolutely
discussing
on
the
mailing
list
to
to
to
check
whether
the
issue
is
considered
solved
with
the
current
television
is
something
that
can
be
done.
C
I'm
not
being
told
that
I
can
speak
but
since
nobody's
speaking
yeah,
if
you
tell
me
okay,
the
applicability
is
all
the
network
is
built
on
eight
port
switches.
You
know
ethernet,
and
you
know
exactly
how
many
parts
you
have
and
and
the
wires
will
prevent
you
from
trying
anything
stupid
so
yeah
that
will
work.
So
so,
if
you
give
us
an
applicability
statement,
this
is
for
exactly
this
network
where
none
of
the
issues-
and
there
are
multiple
ones
which
killed
80
to
the
155
and
other
stuff,
apply
then
yeah.
Why
not?
C
A
A
G
G
G
G
So
if
we
observe
the
address
we
can
see,
the
entity
in
the
iot
network
will
share
a
common
ipv6,
subnet
prefix
and
below
that.
If
we
further
partition
the
network
into
multiple
levels,
then
each
level
will
own
its
own
network
id
and,
finally,
the
entity
id
is
only
part
of
the
suffix
of
the
ipv6
address.
So
therefore,
all
key
ideas
lets
the
entity
only
know
and
use
its
own
entity
id
and
while
we
delegate
all
the
network
id
and
the
prefix
matinees
and
operation
to
the
gateway,
routers
next
slides.
G
So,
therefore,
for
the
address
part
of
the
packet
header,
we
can
only
maintain
the
length
of
the
source
address
and
the
destination
address,
followed
by
the
two
variable
lines,
the
source
address
and
the
destination
address.
In
this
way,
we
can
really
compress
the
address
part
of
the
header
and
for
the
network
and
cache
architecture
you
can
see,
we
will
have
multiple
levels
of
the
sub
networks
and
each
level
will
have
a
one
more
gateway
routers.
G
D
G
G
So
here
is
example
of
a
network.
You
can
see
the
external
networks
I've
in
the
ipv6
that
mean
it
allocate.
You
know,
96
prefix,
bit
prefix
to
this
edge
network
and
within
this
edge
network
it
owns
a
32
32-bit
address
space.
We
can
further
partition
this
network
into
multiple
levels.
On
the
left
side
you
can
see
there
are
three
levels
of
network
on
the
right
side.
There
are
two
levels
of
network
so
in
this
network.
G
If,
in
the
first
case,
if
a
node
x,
I
want
to
talk
to
node
y,
since
they
are
both
in
the
same
level
of
network,
so
you
can
see
their
source
address
and
destination
address
are
of
the
same
lens
and
there
there's
no
need
to
go
outside
of
the
level
networks.
They
can
directly
talk
with
each
other
with
their
own
short
address.
G
In
another
case,
if
node
x
want
to
talk
to
node
in
so
they
are,
they
are
in
a
different
sub
networks
and
but
their
common
level
network
is
a
level
one
network.
So
in
this
case
the
node
s
need
first
go
out
of
is
a
local
level,
two
network,
you
can
see.
First,
it
will
go
out,
go
through
the
lg
rb,
a
level
gateway,
router
b,
so
level
gateway,
router
b
will
keep
its
own
network.
Prefix
is
which
is
a
16
bit
bit
long.
G
So
as
this
router,
it
will
augment
the
source
address
with
this
prefix.
So
on
the
left
side,
you
can
see
the
example
here.
The
source
address
changed
then
now
the
source
address
and
the
destination
address
have
the
same
same
length.
Then
it
came
forward
in
the
same
level
of
network
and
eventually
it
will
reach
the
level
gateway,
router
e
and
that
node,
because
the
destination
prefix
is,
is
no
longer
needed.
Then
it
stripped
off
the
this
prefix
then
only
leave
the
node
id
of
the
node
n
and
forward
into
this.
A
G
Yeah,
okay,
that
then
next
slice,
and
so
you
can
so
so
yeah.
So
basically,
this
is
a
address
scheme
to
how
we
can
truncate
or
the
the
you
use
only
the
necessary
part
of
the
ip
address,
and
we
have
a
way
to
incrementally
deploy
it
in
the
current
ipv6
bit
network,
because
it
only
affects
part
of
the
edge
network
and
in
the
following
slides.
I
also
show
that
it's
a
relationship
with
a
current
existing
header
compression
schemes.
G
G
G
A
G
Yeah,
I
think
some
yeah
yeah
many
benefits
some
it's
applicable
to
and
many
different
network
environments
us
and
also
have
some
other
benefits
right,
but
in
terms
of
overhead
saving,
I
I
don't
think
it's
a.
It
can
compete
with
those
other
compression
schemes
because
those
schemes
are
based
on
the
context
based
header.
You
know:
reduction
compression
techniques.
G
We
here
we
only
concern
the
part
of
the
address
and
also
we
can
apply
the
similar
techniques
to
reduce
the
size
of
the
other
part
of
the
header.
But
this
is
note,
may
concern
of
this
draft
here.
We
we
care
only
about
address
and
also
show,
is
a
benefits
to
to
be
applied.
In
many
other
environments,.
A
Okay,
at
some
point,
the
room
will
get
closed.
So
I
don't
know
there's
time
for
any
very
quick
question
or
comment.
Otherwise
we
can
continue
the
discussion
on
the
mailing
list.
So
all
right.
Thank
you.
If
there's
no
further
comment
or
question,
then
let's
end
the
session
here.
So
thanks
a
lot
to
everyone
for
attending
and
contributing
and
making
comments
and
presentations
thanks
a
lot
and
see
you
in
the
next
meeting
and
on
the
mailing
list.