►
From YouTube: IETF115-6MAN-20221107-1300
Description
6MAN meeting session at IETF115
2022/11/07 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
Welcome
come
in
fast
and
your
seat
belts
put
your
phone
to
silence.
Please
appreciate
it
so
welcome
to
six
man,
working
group,
I
hope
you're,
all
in
the
right
room.
Where
else
could
you
be
so
we
have
busy
agenda
so
I'm
trying
to
start
on
time
and
be
quick,
so
we
have
more
times
more
time
for
presentations.
A
A
Well,
you
read
it
right,
so
housekeeping
I
have
few
minor
requests,
please,
even
if
you
are
in
the
room,
try
to
use
the
inside
tool
to
join
the
queue
it's
much
easier
for
for
the
chairs
to
track
the
order
of
people
in
the
queue
if
you
are
all
in
the
virtual
one,
because
otherwise
it's
pretty
hard
to
remember
who
was
the
first
and
after
you
asked
your
question
made
your
comment:
please
leave
the
queue
when
done
and
state
your
name,
so
the
minutes
taker.
Thank
you.
B
A
C
A
A
Yes
and
the
remote
participants,
please
keep
your
audio
and
video
off
until
you're,
actively
speaking,
which
means
you
is
representing
or
you're
as
a
short
sense
of
you
recommended
to
use
a
headset
but
well
up
to
you
so
agenda
as
usual.
We're
gonna
start
with
working
group
documents.
We
have
55
minutes
allocated
for
that.
So
it's
a
four
drafts,
including
Trump's
draft,
which
has
been
revived
some
brought
it
back
from
there.
We
discussed
in
Hope
by
whole
processions
and
again
extension
headers,
I
love
this
agenda.
A
Src
admitted
identifier
draft
and
Retail
information
in
extension.
Headers
again,
then
we
have
six
individual
drafts.
I'm,
not
gonna,
read
as
a
result
out
loud.
You
know
where
to
find
that
gender
right.
We
have
two
talks
in
time
permitting
category
which
means
yeah.
If
we
will
be
very
efficient
today
and
have
additional
time,
we
can
discuss
two
drafts.
If
not,
authors
would
like
to
get
six-man
attention
on
them.
So
please
check
them
out
anyway.
A
What
happened
since
Philadelphia?
Oh,
we
published
an
RFC
congratulations
on
MTU
Hope
by
hope
option.
We
are
making
good
use
of
extension
hiders.
Finally,
right
we're
finding
use
cases
for
them,
application
for
alternate
marking
and
now
in
RFC,
editor
skill.
Finally,
so
should
be
published
soon
and
your
Zone
identifiers
draft
it's
going
through
another
round
of
review.
We
finished
ATF
last
call
got
some
good
comments
and
now
we
have
request
URI
review
and
w3c
review
to
get
more
eyes
on
the
draft.
So
it's
basically
what
is
going
on?
A
Okay,
yeah
sure,
again,
you're
getting
the
same
right.
So
it's
not
just
me.
Okay
and
Sharia
should
be
presenting
his
draft,
which
kind
of
out
of
the
working
group
last
call,
but
we
need
more
cooperation
with
spring
people.
So
we'll
talk
about
that
later
we
have
a
working
group,
docky.
Okay,
sorry,
let
me
try
another
SSID.
B
A
That's
called
dog
food
I,
don't
know
2
000,
probably
right.
V6
a
pv6
is
hard.
Let's
go
shopping,
okay
now,
where
was
I
yeah,
so
work
in
group
drafts?
Four
of
them
are
presented
today
and
there
is
a
one
draft
which
is
still
a
work
in
group
draft,
but
we
have
not
heard
anything
from
the
authors,
no
updates,
so
we
don't
know
what's
going
on
there
and
the
last
thing,
as
you
might
have
noticed,
we
are
talking
a
lot
about
srv6
in
this
room
as
well.
A
So
we
started
to
think
how
much
can
we
duplicate
the
work
and
how
shall
we
share
responsibility
between
two
working
groups
here?
So
just
to
let
you
know
there
is
an
ongoing
discussion
between
a
six-man
and
spring.
Oh,
so
it's
not
V6,
I
dropped
off
and
I
was
on
dual
stack:
SSID,
okay,
so
we're
talking
about
what
shall
we
do
because
obviously
srv6
has
something
to
do
with
IPv6,
so
sometimes
six
month
involvement
might
be
required.
However,
the
question
is
at
which
stage
and
how
much
of
that
involvement.
A
This
would
that
would
allow
us
to
avoid
the
situation
when
we
get
in
a
lot
of
spring
srv6
related
document
here,
without
even
knowing
if
the
problem
is
worth
solving
from
routing
perspective.
So
that's
all
I
have
any
last
minute
comments:
agenda
version,
complaints.
A
D
This
talk,
let
me
get
stable
with
my
glasses.
This
talk
is
about
the
hopper
hop-up
option,
processing
draft
like
side,
please,
so
we've
progressed
this
to
RAV4.
D
There
are
some
open
issues
we'll
talk
about
with
in
the
data
tracker,
there's
some
data
about
hop
by
hop
on
internet
paths
and
there's
some
comments
on
what
we
think
are
the
next
steps.
So,
first
of
all,
the
changes
changes
from
zero
one
to
zero.
Four,
we
wrote
quite
a
bit
of
things
and
we
didn't
change
the
the
overall
goal,
but
we
provided
much
more
Separation
on
the
difference
between
hardware
and
software
processing,
trying
to
avoid
this
magic,
fast
path,
slow
path
term,
which
we
think
we
now
have
done.
D
We've
also
cited
the
ietf
V6
Ops
hot,
by
hop
draft,
which
clearly
is
related
to
this
whole
whole
subject
of
how
do
you
get
hot
by
hop
options
through
the
internet
and
we
added
the
security
considerations
text
which
we
had
pending
for
a
while
and
I
think
that
that
now
is
ready
for
a
comment
for
anybody.
It's
now
in
the
end
of
the
draft
in
security
considerations,
and
there
were
various
improvements
by
editors
and
various
people
who
commented
on
the
list.
Thank
you
ever
so
much
for
doing
so.
Please
do
read
it.
D
The
intent
here
is
to
get
the
hop
by
hop
options
in
the
hopper
Hopper
extension
headers
Deployable
for
people
in
the
network,
so
they
are
not
filtered
but
actually
passed
in
a
way
which
will
let
the
network
evolve.
To
make
that
happen.
We
have
to
use
some
keywords
like
should
a
must,
and
it
turns
out
that
even
people
who've
written
lots
of
drafts
in
the
past
find
it
hard
to
balance
the
use
of
sugar
must
when
it
comes
to
this
particular
draft.
D
B
D
Yeah,
this
is
very
context
dependent,
it
appears
very
easy
to
say,
should
a
must,
but
when
you're
talking
about
a
draft
work-
oh
well,
I'm
not
doing
this
can
I
take
the
question
later.
David.
E
Sure
I'll
tell
you
what
my
question
is,
but
I'm
fine,
for,
if
you
don't
answer
it
or
whatever,
which
is
just
some
of
the
wordings
in
there
is
very
vague,
like
low
and
reasonable,
and
those
are
things
that
one
would
normally
never
use
in
a
statement
with
most
or
should
because
it's
too
ambiguous.
E
D
D
We
had
used
an
issue
tracker.
We
kept
careful
tracking
of
the
various
things.
D
D
We're
still
expecting
them
to
do
so
when
they're.
Looking
at
these
options,
the
use
of
fast-pass,
slow
path
fast
and
low
and
high
end,
whatever
else
are
still
things
that
we
have
to
get
right,
but
I
think
they
are
words
where
we'll
have
Precision
but
they'll
be
hard
to
get
exactly
precise,
and
we
think
both
of
these
will
be
addressed
in
revision.
Zero.
Four,
so
that's
why
I
was
encouraging
people
to
read
the
draft.
D
Do
you
want
to
grab
a
go
Bob
for
a
second
I?
Don't
know
what
I
I
go?
Okay,
and
so
what
are
the
key
differences
in
the
eh
limits?
Draft
there's
a
related
draft
and
everybody
knows
that
by
hop
options
are
carried
in
the
extension
header.
D
The
extension
header
is
one
of
a
number
of
extension
headers
that
can
be
present,
and
we
now
have
an
ietf
six-man
work
item
on
the
extension
header
limits
limits,
give
more
guidance
on
how
to
handle
more
than
one
options
the
anode
can
process.
So
clearly,
this
is
a
slightly
wider
context
than
the
hot
by
hop
processing
draft.
D
D
D
One
of
the
things
we've
suggested
on
the
list
was
adding
text
to
our
out
of
order
of
processing
and
the
reasons
you
want
to
avoid
having
an
option
header
causing
a
packet
to
be
delivered
out
of
order.
We
believe
that's
a
very
useful
thing.
We
propose
to
add
that
text
to
our
draft
copying
this
that's
been
already
in
the
eh
limits.
D
So
next
slide
right
some
recommendations.
Let's
get
to
the
what
we
actually
plan
to
do
in
the
next
edit
cycle,
the
hop
by
hop
processing
draft
we
think,
should
Define
the
hot
by
hop
processing
element
and
should
not
look
at
the
number
of
options
in
the
hot
by
hop
header.
So
eh
limits
drafts
should
reference
it.
We
should
reference
the
document
that
we're
editing
and
we
think
they
should
cite
the
text
but
not
Define
how
the
hot,
by
hop
options
are
processed.
D
The
eh
limits
drafts
should
continue
to
define
the
total
eh
limits,
and
we
don't
propose
to
elaborate
on
that.
So
I
think
the
right
place
to
do
is
to
provide
comments
to
the
document
that
Tom
Herbert's
editing
to
describe
the
extension
header
limits,
rather
than
discuss
them
in
the
hot
by
hop
processing
draft.
D
D
D
D
The
word
normally,
but
it's
probably
a
good
choice,
to
suggest
that
you
go
through
all
these
little
steps
that
you
do
when
you
fold
a
packet,
because
there
are
quite
a
lot
of
steps
and
we
can't
possibly
enumerate
them,
but
nodes
must
do
that.
Normally,
when
the
hot
by
hop
option,
header
is
not
processed,
not
drop
when
processing
the
HotBox
option.
D
Header
nodes
must
process
the
first
hot
by
hop
option
our
nodes
May
process
more
and
we
weren't
going
to
expand
that
and
leave
Tom
Herbert
to
make
more
overall
overarching
and
discussions
of
how
big
an
extension
header
you
might
like.
So
this
was
our
proposed
resolution
of
separating
these
two
drafts
and
coming
up
with
something
which
satisfies
we
hope.
The
discussion
on
the
list.
D
B
F
It's
good
to
hear
you
good
to
hear
you
too
reading
through
your
draft
and
Tom
Herbert's
draft
I
read
through
them
both
assumed
that
they
would
both
become
rfcs
and
then
said
to
myself.
Okay,
if
we
had
known
all
this
stuff
five
years
ago,
when
we
wrote
8200
the
section
on
options
and
the
section
on
the
Hop
IHOP
extension
header
might
be
different,
but
it
was
a
bit
of
a
task
to
figure
out.
F
You
know
how
they
might
be
different.
Would
it
be
a
good
idea
to
merge
your
draft
and
towns
and
in
that
draft,
just
put
replacements
for
that
section
on
options
in
the
section
on
hop
by
hop
extension,
headers,
so.
D
Possibly
I
I
think
in
the
as
as
Tom's
being
starting
to
formulate
his
extension.
Headers
ID
he's
maybe
created
quite
a
lot.
Novel
overlap,
which
we
didn't
imagine
would
be
there
and
part
of
the
talk
today
is
trying
to
pull
those
apart.
So
they
are
not
too
different
documents
talking
about
the
same
thing,
but
they
talk
about
very
specific
topics.
D
The
extension
headers
part
probably
mainly
refers
to
people
with
Nicks
and
then
stacks
and
people
are
implementing
IPv6
as
opposed
to
people
who
are
doing
routers
or
routers,
who
maybe
are
more
interested
in
the
hot
by
hot
processing.
So
I
don't
know
if
that
answers
your
question,
because
I
think
clearly
what
you
propose
could
also
be
done.
So
we
could
do
what
you
say,
or
we
could
try
and
keep
these
two
documents
as
two
separate
documents.
D
Bob,
do
you
have
another
comment
on
that?
One.
D
D
F
Okay,
the
changing
the
block
of
8200
once
with
the
intent
of
both
drafts
would
make
would
put
the
task
of
synthesis
on
the
authors
as
opposed
to
having
each
reader
synthesize
the
tool
and
figure
out
what
8200
would
look
like.
Had
we
known
all
this
stuff
five
years
ago,
I'd
also
like
to
comment
that
there
are
some
folks
like
plms
from
router
companies
who
need
to
read
and
Implement
both
so.
I
So
one
of
the
things
you
throw
up
as
like
the
first
option,
you
need
to
look
at
it
right,
so
I
just
want
to
point
out
like
nothing
against
or
for
it
right,
but
it's
a
certain
change
in
how
we
treat
Hub
IHOP
options
because
you
they
were
never
treated
us
ordered
and
I
know
like
we
talked
about
this
quite
a
bit
in
connects
right
like
we
were,
throwing
this
as
the
first
option.
I
There's
no
special
thing
for
first
option
right,
so
I
think
I
just
want
us
to
be
cognizant
that
we
are
actually
making
this
change.
That,
like
you
know,
first
option
is
somehow
special
and
the
second
order
effect
is
like
there's
going
to
be
options
that
are
going
to
be
jogging
to
be
the
first
option
right.
I
just
want
to
make
sure
that
it's
noted
somewhere
because,
like
I,
think
this
becomes
like
a
privileged
place
for
an
option
to
be
so.
I
just
wanted
to
know
that
somewhere,
yeah.
D
And
I
think
that's
fair
enough.
I
think
also.
That
means
that
putting
the
option
on
every
packet
may
not
be
something
that
you
should
now
do,
because
that
means
you've
kind
of
trumped
everyone
else
exactly.
J
Okay,
I
wonder
otherwise
this
additional
information.
In
fact,
we,
when
we
deployed
this,
the
IPv6
the
enhance
the
Innovations
such
as
the
srv6
and
IPv6
based
on
network
slicing
in
the
existing
Network,
so
that
we
also
encounter
this
issues
about
the
process
of
this
hobby
header
and
the
definition
of
header
and
also
the
process
in
the
processing
these
options
in
these
headers.
So
in
order
to
solve
these
issues,
we
propose
the
one
draft
that
is
to
use
this
protocol
extensions
to
the
vertex.
J
D
D
So
this
is
a
two
slide
picture
from
an
iepg
talk
which
is
in
the
proceedings,
so
what's
done
by
Anna
Aberdeen
and
basically
it's
doing
the
exploration
of
which
packets
might
get
through
the
internet
if
they
had
extension,
headers
applied
to
them.
D
Is
there
a
limit
on
size
because
people
talked
about
the
size
of
packets
and
mattering,
and
we
have
traversal
rates
for
extension,
headers
of
different
sizes,
and
we
have
hot
by
hop
in
black
and
destination
options
in
blue,
and
you
can
see
the
traversal
rate
for
Destination
options
on
the
tests
we
did
across
the
internet.
D
If
you
want
more
look
at
the
iepg
talk,
this
is
just
a
teaser
where
there's
a
lot
more
data
from
Anna
and
other
people,
but
basically
gestation
options
get
through
a
lot
more
than
hot,
by
hop
options,
not
surprising
hot,
by
hop
options
do
get
through
this
difference
between
TCP
and
UDP.
D
If
you
want
to
tell
us
why
that
would
be
fun,
and
not
necessarily
the
mic,
but
do
catch
up
with
us
and
tell
us
what
what
you
think
about
the
data
but
basically
extension
headers
with
hop
options
which
come
to
a
40,
byte
extension
header
appear
to
get
through
just
as
what
just
as
well
as
any
other
size.
So
we
can
easily
think
that
one
header
will
get
through
reasonably.
D
If
you're
going
to
formulate
a
big
header
chain,
then
the
probability
of
successful
transmission
reduces
why
40
bytes
I,
don't
know
if
you
make
routers
or
routers
or
firewalls
or
whatever
and
know
where
this
number
comes
from
tell
us
it
helps
to
be
the
same
size
as
an
ipv4
option
header.
So
maybe
people
think
that's
okay,
what
part
of
an
IP
ATM
cell
or
whatever
I
don't
know,
but
40
bytes
is
okay,
so
everything
we've
said
in
our
draft
appears
to
be
good
for
this
next
slide.
D
Then
then,
the
question
is
where
on
the
path
do
things
get
dropped
and
a
lot
of
the
packets
that
carry
out
extension
headers
get
dropped
pretty
quickly
as
they're
sent
from
a
home
or
ISP
Network
as
they
get
to
the
first,
as
most
of
the
drops
that
occur
will
actually
have
occurred,
maybe
on
the
first
top
second
hop,
so
the
packets
don't
make
very
far
into
the
internet
when
they
don't
go
so
those
packets
that
are
dropped
are
dropped
very
quickly,
probably
by
policies.
D
I
would
imagine,
which
is
probably
the
reason
why
we're
writing
this
draft
to
say,
please
don't
have
this
policy
much
more
data
in
the
big
talk,
I'm
conscious
of
time,
but
nalini
is
asking
a
question
and
is
definitely
the
right
person
to
ask
a
question
which
you
can
reach
the
mic.
K
That's
right:
that's
right!
Hi,
Melanie,
Elkins,
I'll,
just
I'll
keep
this
really
short,
but
but
our
you
know,
while
I
understand
we're,
not
the
protocol
police
there.
It
seems
to
me
from
our
testing
there's
a
few
organization,
a
handful
of
organizations
in
particular.
If
they
would
change
some
of
their
behavior,
we
might
see
you
know
the
80
20.
We
might
see
a
great
deal
of
improvement.
So
thank
you
for
all
your
testing.
D
And
that's
why
we
had
to
talk
at
iepg
that
you
might
want
to
look
at,
particularly
if
you
run
IPv6
networks,
which
you
should
next
slide.
Please
these
are
things
we
learned.
Some
parts
do
support
by
hop
options.
It's
not
the
game's
not
over
there's
a
chance
of
using
this,
and
you
have
to
choose
a
path.
Try
it
and
see
if
it
works,
ready,
currently
drop
packets
with
a
hot,
hop,
hop
extension
header,
and
that
happens
very
early,
and
some
people
are
much
more
prevalent
at
doing
this
than
others.
D
Limiting
the
size
of
accession.
Header
did
improve
traversal,
so
one
expecting
one
hot
by
hop
option
to
get
through
is
much
better
than
just
saying
an
arbitrary
number,
as
we
did
in
the
original
IPv6
spec.
So
we
think
the
recommendations
we've
made
in
the
hot
by
hot
processing
draft
would
seem
to
help
and
final
slide.
D
We
have
always
to
get
the
language
right.
We
think
the
current
drafts
much
better
we're
about
to
push
a
new
version.
There's
work
to
align
this
with
the
eh
limit
draft.
D
Whichever
way
we
go,
we
have
to
get
the
language
correct.
We
have
to
get
the
dependency
correct.
We
believe
the
dependency
could
follow
what
we've
outlined
in
this
talk.
We
listened
to
Tom's
talk
afterwards
and
then
discuss
with
him.
We
think
this
could
go
to
working
group
last
call
soon.
D
I
am
personally
as
one
of
the
editors
not
sure
that
we
need
to
wait
for
the
eh
limits
draft
to
complete
before
this
is
working
group
last
called
I
think
we
can,
with
a
reasonably
high
probability,
separate
the
two
and
complete
this
first
item.
D
A
L
I'm
going
to
talk
about
the
other
draft
about
extension,
headers
next
slide,
please
so
status
is
working
group
item
there's
been
some
less
discussion,
mostly
inspired
by
Brian.
Carpenter
I'll
touch
a
little
bit
about
that,
similar
to
the
hop
by
hop
processing.
L
We
think
this
is
ready
to
go
to
working
group.
Last
Callison
would
like
to
see
more
activity
on
the
list,
so
please
read
and
provide
feedback
next
slide.
L
So
we
have
version
one:
the
changes
were
relatively
minor.
There
was
one
changed
in
the
padding.
Previously,
it
said
no
more
than
eight
bytes,
but
really
the
maximum
amount
of
padding
should
be
seven
bytes
that
guarantees
that
we
can
align
any
option
to
a
fine
alignment.
L
We
need
to
correctly
reference
rc8504.
Instead,
RC
8200,
the
default
limits
intermediate
destination
off
for
processing
options
is
16.,
so
16
is
based
on
pretty
much
all
the
nodes.
Where
we
wanted
a
on
receive.
We
need
to
have
a
default
limit
to
how
many
options
they
really
should
process
and
the
16
is
actually
both
the
padding
and
non-padding
options
and
other
than
that
there
were
a
number
of
edits
in
the
document.
L
Next
slide.
Please
so
I
did
the
comparison
with
processing.
Corey
went
over
a
lot
of
this,
so
I'll
maybe
give
the
perspective
from
the
eh
limits
draft.
So,
first
of
all,
I
think
the
focus
is
different
and
for
that
reason,
I
do
agree
that
these
should
be
separate
drafts.
The
hubby
hop
processing
really
is
about
processing,
The,
Hop,
I,
hop
options
and,
and
that
seems
to
be
guidance
directed
towards
implementers
or
routing
vendors
in
eh
limits.
It
really
is
about
requirements.
L
We
want
to
provide
specific
numbers
specific
limits.
Most
of
the
draft
is
actually
that
it's
a
very
specific
requirements.
It
goes
down
into
some
of
the
details
of
extension,
header
processing,
in
particular
for
Hoppa,
help
options
and
destination
options.
It
enumerates
all
the
limits
about
padding
number
of
options,
the
possibility
to
set
length
per
option.
L
So
it's
very
much
on
the
on
the
side
of
what
are
the
limits.
What
we
don't
do
when
the
age
limits
draft,
though,
for
instance,
is
discuss
the
Fastpass
flow
path,
split
or
any
guidance
around
actually
implementing
this
also
I
think
there's
less
of
a
distinct.
We
distinguish
less
between
high
performance,
routers
and
other
devices.
What
we
do
distinguish,
though,
is
there's
a
requirement
specific
to
end
devices
host
devices
by
sending
and
receiving
extension
headers,
as
well
as
intermediate
devices
how
they
process
that,
and
also
for
Destination
options.
L
L
So
the
second
difference,
that's
where
we
talked
about
nodes,
must
process
the
first
hop-by-hop
option
in
HP
hvh
processing.
It
looks
like
that's
going
to
be
relaxed
a
little
bit,
but
the
difference
here
is
any
age
limits.
The
first
option
really
isn't
special.
The
idea
is
that
a
device
can
set
a
limit,
how
many
options
are
processed,
and
these
options
in
our
processed
must
be
in
order
starting
from
the
first
one.
So,
for
instance,
the
default
that
we
recommend
is
intermediate.
L
Nodes
should
process
up
to
eight
hop
by
hop
options,
non-padding,
which
means
when
they
receive
a
packet
they
if
they
process
hobby,
hop
options.
They
should,
by
default,
try
to
process
the
first
date,
but
they
can
process
any
number
between
0
and
N.
So
zero
is
the
RFC
8200
recommended
or
guidance
that
allows
that
and
would
be
some
number
of
contiguous
hop-by-hop
options,
padding
and
non-padding,
and
that
would
apply
to
both
Hoppe
hop
and
destination
options.
L
So
then,
once
we
decide
that
we
only
process
part
of
the
options
or
some
of
the
options
and
not
the
full
options,
the
question
becomes
What
Becomes
of
the
rest
of
the
options
so
happy
hop.
Ops
processing
says
that
I
know
it
may
process
the
first
one
and
skip
the
rest
and
eh
limits.
I
think
we're
a
little
more
specific.
L
L
The
Final
Destination,
the
behavior,
is
a
little
bit
different.
The
destination
host
and
I
believe
this
is
consistent
with
RFC
8504
can
process
the
first
n
options
as
a
limit,
but
if
there's
options
beyond
the
limit,
the
host
must
drop
the
packet.
The
rationale
there
is,
unless
the
host
processes
the
full
list
of
extension
of
options,
it
wouldn't
know
if
that's
a
malformed
packet,
so
the
host
does
have
to
process
all
of
the
options.
What
this
means
is
in
practicality
is
that
even
hosts
are
going
to
have
limits.
L
For
instance,
we
can
process
hundreds
and
hundreds
of
options
in
a
single
packet
efficiently.
No
one
can
do
that.
That
also
be
the
only
use
case
has
a
denial
of
service
attack.
So
we
think
that
the
host
does
need
this
requirement
and
does
need
to
drop
when
the
limits
are
exceeded
next
slide.
Please.
L
L
We
recommend
sending
up
to
eight
non-padding
options
as
the
default.
The
rationale
here
is
that
whether
or
not
one
or
zero
is
sent
is
a
bigger
difference
than
sending
more
than
one,
especially
if
we
allow
intermediate
nodes
to
ignore
options
past
the
first
one.
That
means
that
the
only
thing
special
about
the
first
option
really
is
the
fact
that
it
it's
the
most
likely
to
be
processed,
but
in
environments
where
the
source
knows
that
the
path
can
handle
more
than
one
option
or
has
a
need
to
process
more
than
one
option.
L
There's
really
no
need
to
to
limit
it
from
the
sender,
with
the
assumption
that
intermediate
nodes
don't
care.
Obviously,
when
we
start
talking
about
the
limits
of
the
header
chain,
this
would
be
relevant,
but
that's
actually
a
separate,
separate
topic.
How
many
bytes
you
can
have
so
I
think
the
limit
is
requirement
here
is
assume
the
eh
limits.
L
K
L
Last
major
difference
is
around
the
area
of
how
big
extension
header
chains
can
be.
How
by
hop
options,
gives
this
guidance
should
not
hobby
hop
option
should
not
be
a
variable
size
that
can
extend
beyond
what
can
be
executed
in
a
fast
path.
Eh
limits
is
more
specific.
The
current
limit
that
we're
proposing
is
64
bytes
maximum
of
extension,
headers
the
whole
IP
V6
header
chain
fits
in
a
128
bytes,
as
I
said
on
the
chat.
L
That's
a
little
bit
inconsistent
with
this
data
that
shows
48,
bytes
are
commonly
able
to
be
transmitted,
so
I
think
that's
an
interesting
question
why
48
bytes,
but
the
rationale
here
was
devices
should
be
able
to
parse
with
a
parsing
buffer
of
128
bytes
and
that
would
fit
an
Ethernet
header
or
IPv6
header
and
the
first
eight
bytes
of
Transport
header,
plus
64
bytes
of
ethernet
of
ether,
extensioner,
sorry,
so
I
think
we
do
need
this
requirements
probably
are
appropriating
age
limits,
but
obviously
there's
maybe
some
discussion
on
what
the
actual
numbers
next
slide.
L
L
So
that's
all
I
have
for
today.
Thank
you.
A
D
Okay,
if
we're
shorter
time,
I
think
we
could
take
this
to
the
list,
but
clearly
Tom.
It
would
be
good
to
work
with
you
to
get
a
coherent
set
of
recommendations
for
both
drafts.
M
L
D
M
That
hi
Tom
this
is
Tim
winners,
QA
Cafe,
so
80
8504
has
text.
Are
you
planning
on
updating
that
text?
Is
this
draft
going
to
be
an
update
of
that,
or
is
it
essentially
the
same
I'm
gonna
read
it
in
diff
the
two,
but
that
was
my
other
question
here
is
if
you
were
actually
trying
to
update
General
node
requirements,
and
what
do
you
wanted
to
do
about
that.
L
I
I
think
it
does
update
8504,
so
I
wanted
to
make
that
put
that
label
on
the
draft.
I
Thanks
next
slide,
thank
you.
So
the
draft
completed
last
call
in
six
months,
so
I
think
it's
not
officially
closed
yet
right
Jen.
So
there
is
some
comments
like
pending
from
Spring
and
I
have
a
slide
to
talk
about
it.
But
thanks
to
everybody
who
commented
like
I
was
actually
pleasantly
surprised.
I
How
much
we
got
like
especially
Adrian,
thanks
for
your
review,
like
that
was
like
amazing,
there's
quite
a
bit
of
stuff
and
and
a
lot
of
it
has
been
around
tightening
the
language
so
like
we
so
I
was
using
like
language
for
routing
and
forwarding
kind
of
interchangeably,
and
that
could
be
read
from
somebody
from
the
routing
area
differently
than
how
we
would
read
it
in
Sixth,
Man,
so
I
think,
like
it
didn't
kind
of
helped
quite
a
bit
in
tightening
the
language
around
it.
I
So
that's
been
done
so
like
pretty
much
all
the
comments
received
during
the
last
call
have
been
addressed
and
there's
like
one
specific
one,
I
had
to
call
out
like
Edward
Metz.
It
came
like
a
week
after
last
call
but
I
think
it's
still
worth
addressing,
but
I
didn't
want
to
do
it
like
one
day
before
the
submission
deadline
to
just
rush
something
but
and
that's
something
we
I
should
like
address
after
the
ITF
complete
right
and
and
the
key
thing
to
sorry.
I
Okay,
I
can
just
talk
to
Jen,
don't
worry
so
the
the
key
thing
is
like
to
talk
about
the
prefix.
That's
getting
allocated
to
say
it's
gonna
be
optional.
Okay,
I
think
people
are
trying
to
read
my
lips,
so
I'll
just
go
so.
I
The
key
thing
is
this:
use
of
this
prefix
is
optional,
so
nobody's
going
to
be
forced
to
use
this
prefix,
and
so
that
is
I
thought
it
was
always
understood
from
the
draft
that
is
like
getting
a
prefix
for
use
for
somebody,
and
but
people
had
like
specific
questions.
Saying
hey:
should
we
use
this
for
Sr
all
the
time
right?
So
that
is
not
the
intent,
so
I'll
add
in
text
in
there
saying
this
is
use
of
this
is
optional.
I
So
that's
going
to
come
in,
but
I'll
circulate
the
text
on
the
list
before
adding
anything
like
that.
But
the
point
is
right
by
allocating
this
prefix
like
nobody's
going
to
go:
ask
for
a
prefix
just
for
doing
Sr,
I,
think
that
is
the
goal
of
doing
this
and
a
couple
of
days
back
just
before
the
ITF
I
got
a
mail
from
Ayanna,
along
with
the
chairs
and
the
ad.
So
this
is
awesome
right
like
this
is
like
an
amazing
process
that
Ayanna
is
actually
doing
earlier.
I
Use
of
drafts
for
Ayana
things
and
I
was
like
really
presently
surprised.
So
thanks
Amanda,
if
you're
like
you
know,
looking
at
it
so
I
just
put
together
a
straw
man
proposal
for
how
the
prefix
is
going
to
look
in
the
special
purpose
registry.
And
if
you
look
at
it
it's
it's
very
similar
to
what
Ula
does.
Okay,
so
the
the
it's
a
forwardable
prefix.
So
it
means
it
can
actually
cross
a
router
because
as
long
as
you're
in
a
domain,
the
the
router
should
be
able
to
forward
it.
I
So
it's
not
like
link
local.
So
that
is
really
what
the
forwardable
thing
means
and
the
globally
routable
is
false,
because
there
has
been
actually
some
proposals
during
working
group
last
call
which
said
like:
oh,
we
should
like
make
it
centrally
registered
and
we
allow
it
routing,
but
I
don't
think
we
started
off
with
that
intent.
Okay.
So
if
somebody
wants
to
discuss
that,
that's
fine
but
I,
don't
think
that
is
what
this
trust
got
out
to
do.
I
Okay,
so
this
was
like
for
somebody
to
use
it
on
a
best
case
basis
inside
a
domain,
so
we
don't
really
want
to
have
a
registry
or
like
make
something.
That's
like
globally
unique
going
forward
on
this,
so
Maestro
man
proposal
again
is
like
globally.
Routable
is
going
to
stay
false
and
the
protocol
field
is
false
as
well.
I
I
think
it
should
be
like
one
thing
down,
but
moving
to
PDF
got
rid
of
it,
but
the
protocol
field
is
false,
because
if
the
protocol
field
is
true,
then
all
IP
compliant
implementation
should
support
this
Behavior
so
which
is
something
we
don't
want.
So
like
it's
going
to
be
false
in
there.
So
this
is
the
proposal.
Of
course.
It's
going
to
go
on
the
list
as
like
a
discussion
Point
as
soon
as
like
spring
completes
their
review
of
the
issue
list
right.
That's
in
the
draft
next
slide.
I
Okay,
so
so
I'm
going
to
put
in
this,
like
new
text,
I'll
circulate
the
text
for
adding
this
prefix
use
optional
thing
just
to
make
sure
that
it's
it's
clear
to
everybody
and
I,
don't
miss
anything
obvious
in
there
and
again
thanks
everybody
for
like
committing
during
working
with
last
call.
I
Think
Jen
has
already
sent
a
reminder
to
the
spring
chairs
to
kind
of
close
this
right,
and
so
the
comments
that
are
actually
received,
I
think
like
droops,
and
something
there's
like
two
or
three
people
who
commented
from
spring
on
this.
Who
said
like
it's
fine
to
move
the
issue
list,
but
as
long
as
there's
an
official
conclusion
from
Spring
chairs
I
see
Joel
back
there.
So
if
spring
concludes
that
the
issue
is
just
fine
to
move
over,
then
I
think
we
can
close
that
part
of
it
on
the
draft.
So
did
I.
B
I
J
Okay,
today,
I
will
do
the
presentation
about
carrying
video
information
in
IPv6
extension
header.
So
this
is
regarding
the
network
slicing,
or
this
is
called
the
network
resource
partition
in
the
teeth
working
group.
Okay,
next
slide,
okay,
so
here
this
is
the
background.
So
in
fact,
in
this
draft
is
introduce
a
new
IPv6.
How
about
half
option
to
carry
this
network
resource
partition
information
in
IPv6
packet
so
that
this
can
use
by
Network
nodes
to
identify
the
vtn?
J
The
package
that
belong
to
and
forwarding
the
packet
based
on
the
resource
indicated
by
the
reading
identifier,
so
the
meeting
option
can
be
used
to
ipv,
ITF
or
network
slices
and
maybe
could
also
be
used
in
other
scenarios.
So
this
this
topic
has
been
proposed
in
the
past
ietf
meetings
so
that
they
think
about
how
to
use
a
generalize
this
waiting
option.
So
this
chart
this
presentation,
we
will
focus
on
topic
so
next
slide.
J
Next,
yeah,
okay,
in
fact,
in
the
teeth
working
group
we
propose,
one
draft
is
discussed
about
this.
The
possible
generalized
generalization
use
cases
about
the
ietf
network
slicing
so
that,
from
our
point
of
view
in
the
existing
the
IPv6
waiting
options
because
we
have
the
flag,
we
also
have
this
video
resource
identifier.
We
can
use
a
different
flag.
I
can
generalize
the
written
resource
identifier
for
different
purpose,
so
that
means
existing.
J
The
mechanism
of
this
option
can
support
the
generalization,
but
the
most
important
thing
is:
what's
the
use
case
and
how
water
identifier
can
be
generalized
use
this.
This
existing
Vision
resource
identifier,
so
this
this
draft
in
the
teeth
working
group
we
talk
about
the
possible
user
cases
can
be
generalized
based
on
this.
J
The
waiting
resource
identifier
it,
including
the
possible
that
used
to
indicate
the
topology,
is
used
to
indicate
the
resource
not
only
for
the
bandwidth
isolation,
but
also
for
the
some
other
service
functions,
such
as
security
or
the
network
management,
and
also
you
know
that
Network
slicing,
we
have
the
different
topology,
maybe
there's
the
multiple
MP
to
MP
topology.
It
also
can
be
the
P2P
topology.
J
J
Okay,
so
this
so
okay,
so
this
is
Nexus
slice
I
think
they
finished
okay.
So
here
this
is
just
some.
This
talk
about
this
thinking
on
the
generalization
of
the
meeting
semantics,
so
we
think
that
this
network,
we
think
that
the
identifier
of
this
the
waiting
resource
it
should
be
associated
with
a
set
of
network-wide
attributes.
That
means
we
Emerald
side.
That
is
a
network-wide
instead
of
the
subrosification
node
or
the
past
subrosific,
past
identifier,
that
is
here.
J
That
means
this
should
be
the
network
wider
attribute
instead
of
the
password
or
the
node
wide.
So
that's
the
the
first
one
to
if
we
wanted
to
do
the
generalization
we
first
to
identify
this
one.
So
this
is
the
first
one,
second
one
so
that
we
think
what
this
network
attribute
can
be
identified.
So
we
think
that
currently,
that
is
the
first
that's
related
with
the
a
regional
Network
slicing,
which
is
the
link
bandwidth
and
also
with
some.
This
is
the
average
of
this
queue.
J
That's
used
to
guarantee
the
SRE
for
the
network
slicing,
so
I
think
this
is
a
region,
meaning
I
mean
so
this
is
also
here.
They
are
so
some
generalization
is
not
only
the
bandwidth
but
maybe
other
resource
to
guarantee
the
SRE,
the
second
one
we
think
the
network
attribute.
That
is
the
topology
attribute,
because
this
topology,
let's
use
Network
wide.
So
here
we
identify
the
possible
Network
topology
and
the
P2P
p2mp
and
mp2p,
or
the
mp2mp
that
is
identified
the
different
this
topology
attribute
the
third
one.
J
J
So
I
think
that's.
We
think
this
is
important
to
identify
the
boundary
of
the
generalization.
We
think
this
maybe
is
too
hard
just
to
set.
That
is
just
generalized
identifier.
It
can
be
everything
it
can
be
anything
in
the
future,
so
we
think
that
we
can
generalized,
but
we
also
use
this
use
cases
to
identify
the
scope
of
this
generalization
of
the
written
resource
identifier.
G
J
In
fact,
this
first,
though,
I
think
I
I
have
explained
this.
The
purpose
about
the
generalization
I
think
in
ietf.
When
we
do
some
this
the
protocol
specification,
it
should
be
firstly
identified
by
the
use
cases,
so
I
think
for
the
generalization.
I
think
that
we
must
to
identify
what's
the
user
cases
and
what's
the
identifier
can
be
generalized.
J
This
is
the
first
point.
The
second
point
I
think
in
the
existing
existing
the
written
options.
It
also
remaining
the
capability
for
the
filter
for
the
filter
extension,
because
we
have
the
result
of
the
flags.
You
will
use
a
different
flag
so
that
the
flag,
so
that
indicates
the
different
meaning
of
the
written
resource
identifier,
so
I
think
even
in
the
future.
If
some
use
cases
still
want
to
reuse
this
option
I
think
we
need
not
to
change
this
option
type
and
and
also
use
just
to
use
some
this
new
flag
for
the
generalization.
J
So
this
is
your
second
Point,
okay,
okay,
so
here
so
this
I
just
to
mention
this
way.
So
this
is
this
draft.
We
also
have
some
related
draft.
The
first
draft.
This
is
the
cxma.
That's
a
topology
ID
draft
that
means
use
identifier
to
indicate
the
topology,
so
that
means
the
topology
is
also
a
resource
according
to
the
description
in
the
previous
pages.
J
So
we
think
that
maybe
this
topology
ID
can
directly
use
a
written
resource
identifier,
because
the
written
resource
not
only
include
the
included
resource
attribute,
but
also
indicate
the
topology
attribute
for
the
network
slicing.
So
from
our
point
of
view,
so
that
the
written
resource
identifier
can
directly
use
as
a
topology
identifier,
okay,
but
we
think
that
the
question
is
that,
because
if
this
can
be
used,
topology
identifier,
so
that
means
that
existing
the
features-
the
market
topology
of
the
flex
angles.
J
This
may
be
also
that's
used
created
before
Network
slicing.
In
fact,
they
can
independent
from
the
network
slicing,
but
now
because
this
identifier
kindly
use
the
routine
resource
identifier.
So
that
means
this
multiple
topology
must
be
used
combining
with
network
slicing.
This
is
can
be
accepted
or
not.
We
will
ask
for
the
comments
in
the
teeth
working
group
and
the
igp
working
group
if
they
agree
with
this
one,
so
I
think
this.
J
This
written
resource
identifier
can
be
generalized
to
indicate
the
topology
ID.
This
is
the
first
one.
Second,
one
I
think
this
is
the
password
and
the
affair.
In
fact,
in
the
Supreme
working
group
there's,
the
one
draft
is
related.
The
past
segment.
That
means
user
pass
segment
to
identify
the
Sr
pass,
so
that
user
just
use
some
this
path.
Identifier,
but
I-
mentioned
that
the
P2P
slice,
because
you
suggests,
is
a
point
to
point.
J
In
fact,
so
that's
the
written
resource
identifier
can
be
used
as
the
path
ID,
because
just
just
the
point
to
point
one,
but
from
our
point
of
view
we
think
this.
This
is
just
a
special
case
of
the
network
slicing.
We
think
we
should
not
use
the
routine
resource.
Identifier
become
a
past
identifier,
so,
in
our
opinion
we
think
the
written
resource
identifier
should
be
the
network
identifier.
That
means
all
only
to
indicate
that
neither
World
Network
wider
attribute
is
instead
of
the
past
attribute.
J
If
so,
that
means,
if
you
we
need,
need
some
this,
the
information
regarding
the
past
we
need
to,
in
the
introduce
independent
past
identifier,
in
fact,
instead
of
reusing
the
reusing,
the
written
resource
identifier,
so.
J
Another
last
one
I
think
this.
We
also
have
the
multiple
Distributing
resource
identifier.
That
means
we
have
the
global
for
the
cross,
multiple
domain
and
also
the
local
domain.
That
means
we
have
the
here
we
have.
This
is
the
different
resource
identifier.
We
think
this
this.
We
must
use
independent
identifier
for
the
different
scope.
So
this
is
just
a
third
one.
Okay,
next
page
I
try
to
finish:
okay,
okay,
so
I
think
we
can
go
the
next
one.
J
Okay,
so
I
think
this
is
just
the
major
thinking
about
the
generalization
of
this
meeting
resource
options
and
the
written
resource
identifier,
so
I,
I
I,
also
there's
a
thing:
explain
the
design
thought
about
the
generalization
and
and
also
identify
what
a
resource
I
identifier
can
be
generalized
with
this.
This
one
so
I
wish
you
can
review
this
draft
if
you
and
also
think
this
use
case
does
make
sense
or
not,
if
it's
okay,
so
that
we
just
make
this
as
a
strong
base.
J
A
Thanks
no
questions
I
have
another
USBC,
okay,
next
next
I
guess
next
is
Justin
right.
Yes,
okay,.
A
A
N
Justin,
your
man
Julius,
so
this
draft
is
actually
about
carrying
a
generic
identifier
and
IPv6
packet,
and
this
is
actually
really
close
and
related
to
the
previous
presentation.
N
So
actually,
the
idea
came
to
mind
right
after
previous
meeting
in
Philly,
because
obviously
we
had
two
drafts
with
kind
of
similar
use
cases
and
by
similar
use
cases
I
mean
they
were
trying
to.
You
know,
carry
a
32-bit
identifier
and
the
problem
is
that
they
wanted
to
allocate
a
new
cut
Point
both.
So
you
had
to
create
two
code
points
for
similar
use
cases
right
and
there
were
some
concerns,
and
actually
there
are
still
concerts.
It
looks
like
actually,
so
the
problem
is
that
it's
not
generic
enough
right.
N
So
why
the
second
draft
on
the
list
here
as
expired,
the
first
one
so
which
has
been
presented
right
before
this
one-
has
evolved
to
make
it
more
generic,
but
I
think
it's
more
generic
still
in
that
vtn
context
right.
So
the
question
is:
should
we
do
something
about
that?
And
if
we
choose
to
do
something
well,
there
might
be
several
Solutions.
N
N
N
Thanks
to
that,
you
would
be
able
to
have
a
kind
of
stricter
in
the
data
not
only
an
ID,
but
maybe
several
IDs,
but
also
Flags
or
whatever.
So,
if
I
take
your
draft,
I
know
that,
with
the
new
revision
you
have
Flex,
for
instance,
in
your
structure,
so
it
would
be
possible
but
again
accounts
here
would
be
that
you
have
a
sub
registry,
so
I
don't
think
it's
going
the
right
way,
gory
left
but
I
think
for
the
efficient
processing
of
biops.
N
B
Yeah,
it
would
be
good
to
get
feedback
from
the
working
group
on
this,
because
something
like
this
would
allow
a
way
of
carrying
a
lot
of
identification
information
without
having
to
do
a
whole
new
type
for
each
one.
There
could
be
a
registry
either
they
get,
it
would
be
I
think
an
easier
process
to
get
new
things
done,
but
it's
like
with
all
things
has
carried
off.
So
comments
are
appreciated.
O
I
think
as
Robin
just
mentioned
in
his
presentation,
but
considered
as
a
network
wide
generic
concept
and
cover
a
set
of
network
attributes
which
can
be
applied
to
not
only
Network
slicing
but
also
others
in
a
generic
scenarios.
O
So
my
understanding
is
maybe
we
can
just
follow
the
existing
option
to
make
it
generic,
but
we
before
that
we
can
have
a
base
version
to
meet
the
current
requirements
first,
so,
okay,
thank
you.
C
El
Richardson
I
guess
my
first
question
really
is
to
do
with,
for
or
as
a
question
to
people
who
have
or
who
have
knowledge
of
configurable
Hardware.
That
is
going
to
be
able
to
do
this
is
well.
Can
you
match
this?
Can
you
match
this
intelligently,
or
are
you
limited
to
looking
at
the
option
type
there
so
I
think
that's
a
really
big
question
and
I
mean
you
can
imagine
new
things
can
do
whatever
and
P4
people
can.
C
You
know,
do
whatever
they
want,
but
I
think
the
question
is
going
back.
What
what
is
what
is
easiest?
The
other
part
of
that
question,
I
think
is
based
on
what
I
think
gory
said
at
the
beginning.
Was
that
going
forward
we're
considering
all
types
as
if
they
have
zero
zero
at
the
beginning?
C
Fields
option
types
going
forward,
and
maybe
we
don't
need
to
subtype
it
going
forward,
and
so
that
also
you
know
I,
don't
know
if
that's
really
in
in
practice
what
he
means
or
that's
where
we're
evolving
to
or
you
know
we're
we
have
I
know
we
have
32
option
types
today
available
I
think
we
have
about
nine
or
ten
of
them
in
the
registry,
so
we're
not
exhausted,
but
you
know,
on
the
other
hand,
we're
not
we're
not
super
rich
in
them,
so
I
suspect
that
we
don't
need
a
generic
type
and
that
going
forward
we
can
reclaim
those
zero
zero
bits
for
other
things,
but
that's
not
to
say
that
it
wouldn't
be
good
to
have
a
document.
C
That
said,
these
are
all
the
considerations
that
options
need
to
think
about,
and
it
makes
life
easier
for
the
next
guy.
That's
trying
to
Define
a
specific
option.
J
In
fact,
I
explained
some
of
this
design
Concept
in
my
draft,
so
that's
a
I
also
regarding
this
dropped.
I,
these
comments,
the
first
one,
the
most
important,
is
the
scope
of
the
generalization.
This
is
very
important
for
this
one,
the
first,
because
if
we
let's
use
some
this
context,
ID
and
we
use
some
of
the
data.
If
we
use
this
generalization,
it
can
be
everything.
This
is
not
only
the
video
or
this
support.
It
can
maybe
also
cover
the
information
of
other
IPv6
options,
even,
for
example,
the
MTU
option.
J
You
can
also
use
this
data
structure
to
indicate
I
think
this
definitely
does
not
work.
This
first
point.
The
second
point
is
the
boundary.
If
you
use
this
one
to
identifier,
so
that's
this.
Is
you
this
scope?
That
means
the
data
must
be
identifier
or
can
be
other
things
that
that
means
this
must
because
this
must
be
defined.
This
is
the
identifier.
This
is
the
this.
Is
this
the
evil?
If
this
is
or
not,
this
master
defined
the
third
one,
if
this
is
identify
a
generalized
identifier,
so
this
is
also
the
use
cases.
J
I
mean
mentioned,
because
this
can
be
any
identifiers,
but
maybe
this
identifier
can
be
defined
by
other
draft
and
also
by
other
options,
and
they
maybe
had
they
didn't
this
identifiers.
Maybe
didn't
Maybe
do
not
have
this
comma
attribute
or
this
the
common
meaning.
So
this
is
just
Why
I.
Think
if
we
want
to
define
the
generalization,
we
must
take
use
of
the
use
case
driven
method.
That's
my
point.
J
B
P
Just
a
reminder
that
for
ripple,
we
have
defined
one
option,
which
is
a
hub
option
that
signals
a
topology
repo
is
designed
to
Route
over
multiple
topologies,
and
this
looks
like
a
similar
situation
as
the
vtn.
So
I
was
just
wondering
instead
of
allocating
new
code
points,
if
we
could
extend
the
code
point
that
we
already
have
so
we
we
have
less
discussion
about
how
many
we
have,
rather
than
keeping
this
one
completely
specific
to
repo.
B
Q
That
should
be
connected
online,
and
this
is
about
the
status
of
the
draft
you
see
here,
so
the
usage
of
neighbor
Discovery
protocol
to
support
multi-homing,
multiple
prefix.
So
next
slide.
Please
quickly
the
scope
it
was
presented
at
ATF,
114
Philadelphia.
It's
about
you
know
discussing
the
usage
of
multi-homing,
multiple
prefix,
which
is
a
solution
that
has
several
sorry
it's
a
a
mechanism
that
is
several
Solutions.
We
have
tried
to
look
at
the
open
issues,
just
focusing
on
neighbor
Discovery
protocols.
Q
So
you
see
they
are
the
references
to
the
rfcs,
the
4861
62
and
the
default
address
selection,
70,
67
24..
What
we
have
proposed-
probably
you
remember-
the
discussion
at
the
last
meeting-
is
something
that
apparently
could
be.
Let's
say
criticized
because
it
changes
it
swaps,
the
two
steps
defined
by
6724.
So
instead
of
selecting
first,
the
next
up
router,
we
look
first
at
the
source
address.
Q
So
that's
about
the
the
draft
next
slide
position.
So
what
we?
What
we
did
in
the
past
months,
there
was
a
a
request
from
the
chairs
to
refine
the
problem
statement.
So
we
have
reviewed
the
introductory
section
of
the
draft
and
at
the
ietf
114
we
received
also
some
feedback
about
the
content
of
the
draft,
so
we
included
also
a
kind
of
high
level
analysis
on
provisioning
domains
and
that
brought
to
the
let's
say,
review
of
a
couple
of
sections
of
our
draft.
Q
So
section
number
three,
which
is
about
the
naval
Discovery
protocol
analysis
for
mhmp
and
section
number
five.
Then
we
also
received
a
comment
about
avoiding
overlapping
with
other
ongoing
drafts.
Maybe
that
was
read
to
another
draft
that
we
posted
some
time
ago.
I
guess
not
specifically
this
one,
but
anyway
it
was
the
right
chance
of
giving
a
kind
of
General
revision
to
the
document.
So
we
hope
we
have
done
a
general
cleaning
now
specifically
on
provisioning
domains,
and
we
can
move
to
the
next
slides.
Q
Please,
as
I
said,
we
just
did
a
first
analysis
very
high
level,
so
we
don't
pretend
it's
complete
and
we
are
really
open
to
feedback
and
suggestion
from
the
from
the
working
group.
We
think
we
don't
think
that
there
are
still
some
a
few
open
aspects.
We
are
not
completely
sure
about
that,
but
probably
let's
say
the
issue
is
related
on
the
usage
of
of
the
apis
on
a
host
or
on
a
server.
Q
Let's
say
how
they
are
used
by
the
application,
so
we
have
probably
a
couple
of
use
cases
we
would
like
to
share
with
the
community
just
to
have
feedback,
so
our
question
is:
if
there
is
interested
in
doing
so,
we
would
like
to
share
through
the
main
list
or
any
types
of
offline
discussions,
what
we
have
found
so
far,
one
possibility,
as
I
said,
that
could
be
related
to
the
usage
of
the
apis.
Q
Probably
if
you
would
use
the
bind,
which
is
probably
something
on
the
server
side,
we
will
say
no
problem
at
all,
so
any
type
of
solution
works
and
provisioning
domains
is
more
than
fine.
On
the
host
side.
Probably
there
could
be
something
open
due
to
the
usage
of
get
other
info,
but
here
we
are
not
completely
expert,
so
we
like
to
hear
from
the
community
anyway,
we
are
open
to
the
discussion.
If
there
is
any,
if
there
is
interest,
we
can
move
on
and
share
what
we
have
found.
O
Q
There
is
interest,
just
get
in
touch
and
we
can
share
what
we
have
found
and
again
if
there
is
any
feedback
or
a
proposal
to
extend
the
scope
or
even
criticism,
we
are
more
than
open
to
accept
that
and
also
co-authoring
is
welcome
and
that's
it
so
far.
Thank
you.
B
I
Okay,
certification-
and
so
you
have
you,
followed
the
work
in
interior
that
Eric
was
working
on
before,
and
I
I
think
the
the
scope
of
that,
like
okay,
there
was
a
myth,
working
group
that
was
like
a
lot
of
work
that
was
there
and
the
idea
was
to
shorten
the
thing
to
minimum
thing
required
right.
So
if
you
want.
O
I
Q
For
sure,
thank
you
for
the
suggestion.
As
I
said,
the
idea
is
not
to
extend
the
scope
of
this
draft.
We
really
want
to
focus
just
on
what
we
are
discussing
there,
but
it's
because
we
received
you
know
a
feedback
at
the
previous
meeting,
so
we
just
want
to
be
sure
that
we
are
not
touching
something
that
is
already
there.
So
we
are
not
Reinventing
the
wheel.
Basically,
thanks.
R
Lauren,
the
answer
Lorenzo
clearly
just
a
couple
of
comments:
I
guess
it's
based
on
the
slides,
really,
first
of
all,
I
think
if
you
like
selecting
the
the
address
before
you
before
you
do,
the
the
rooting
lookup
probably
like
doesn't
allow
you
to
implement
like
rule
on,
which
is
to
prefer
like
avoid
unreachable,
destinations
or
something.
So
thank
you.
You
kind
of
like
can't
build
a
straight
line.
R
Algorithm
I
think
maybe
you've
looked
at
this
already
and
for
applications
for
your
other
questions
around
should
applications
use,
you
know,
bind
or
you
pass
the
hint
and
get
that
rinfo
on
those
on
the
source
address
to
use.
I
would
not
advise
relying
on
applications
to
do
that.
R
Right,
like
IPv6
or
stress
selection,
is
actually
really
hard,
and
one
of
the
decisions
that
we
made
a
long
time
ago
in
Android
was
to
like
not
require
them
to
do
bind
they
basically
bind
to
a
provisioning
domain
or
a
network,
and
then
the
stack
figures
out
the
source
address
it's
way
too
difficult,
because
you
have
to
figure
out.
Basically,
you
have
to
implement
most
of
6724
in
the
app
because
you
have
to
you
know,
prefer
temporary
addresses.
You
know
like
avoid
deprecated
addresses,
you
know.
Well,
that's
really
hard.
R
So
yeah
I'm
happy
to
talk
about
this
offline
now
sure.
S
A
S
S
This
is
the
recap
of
this
draft.
This
job
defines
icmb
extensions
to
achieve
iom
abilities
Discovery
in
avi-based
extent
works.
This
chapter
is
a
campaigning
document
of
ibpm
working
group
jobs.
This
chapter
defines
rdb6
node,
iom
information,
currently
mechanism
for
this
mechanism.
Six
iom
capabilities
objects
are
defined
just
like
this.
S
S
The
zero
zero
version
draft
was
presented
at
ITF,
iitf
112
and
the
zero
one
version
draft
was
presented
to
that
itf114.
The
latest
version
is
zero.
Two,
the
maintained
in
zero
two
version
is
that
IPv6
node
information
messages
defined
in
obviously
4620
are
reused
in
some
extensions
to
those
messages
described.
S
S
S
There
is
an
open
question:
considering
of
the
4620,
is
an
experimental
I
see
what
category
does
this
job
belong
to
experimental
standard
track
or
others?
The
authors
believe
this
question
can
be
answered
after
working
group
adoption.
If
this
working
group
would
like
to
adopt
this
job,
that's
like
this.
S
T
Next
slide,
please
I
will
remind
for
start
a
little
bit.
What
is
it
about?
We
still
have
a
security
problem
on
the
link,
because
initially
everybody
believed
that
encryption
will
protect
Navy
Discovery
protocol.
Initially
it
was
apsec,
then
send,
but
then
it
has
been
discovered
that
it's
a
challenge
not
just
because
of
encryption
encryption
by
itself
is
easy.
It
was
a
problem
because
for
encryption
you
need
to
somehow
to
to
some
trust
Authority
some
trust
anchor.
T
You
need
to
some
somehow
to
do
Key
Management,
which
is
which
is
really
a
big
problem
for
many
Enterprises
and
for
the
reason
apcx
and
has
not
become
popular.
It
means
that
it's
still
possible
to
pretend
to
be
men
in
the
middle.
It's
still
possible
to
hijack
some
communication
on
the
link.
If
you
are
on
the
link.
Of
course,
you
need
to
be
on
the
link,
but
okay,
it's
potentially
possible
in
some
situations.
It's
still
it's
still
a
problem.
At
the
same
time,
we
see
that
blockchain
Bitcoin.
T
They
have
a
good
progress
without
trust
to
anybody
without
trust
or
anchor,
but
the
reason
it's
possible
to
develop
something
like
CJ
light,
something
like
simple
version
which
will
connect
IP
address
not
to
the
public
key
or
private
key
as
it
was
in
incent,
for
example,
public
private
key,
but
connected
to
the
MAC
address,
which
is,
by
the
way
in
many
cases,
are
already
more
less
protected,
especially
in
Wireless.
Enviro
is
typically
is
encryption
protected
and
even
for
Wired
dot.
T
T
We
have
intention
to
repeat
the
solution,
but
it's
very
simple:
you
need
to
collect
all
relevant
information,
hash
it
hash
and
hash
and
hash
again
till
you
will
get
some
number
of
leading
zeros
and
then,
if
you
have
an
athlete
in
zeros
up
to
you,
it's
up
to
your
security
requirement.
O
T
T
It
supports
pretty
much
almost
everything.
It's
compatible
to
Temporary
macro
temporary
AP,
address,
of
course,
for
temporary
Mac.
If
it's
a
short-lived,
then
you
need
to
regenerate
it
again
to
do
hash
again
to
to
find
a
new
combination
of
Mac
IP,
which
you
would
like
to
use.
If
you
will
change
MAC
or
you
would
try
to
change
AP,
it's
of
course
a
little
bit
challenge,
but
it's
not
a
big
problem.
It's
compatible
to
almost
everything
except
except
maybe
one
point.
T
It
does
not
protect
against
denial
of
service
because
but
by
the
way,
encryption
does
not
protect
against
the
network
service
too,
because
if
somebody
will
try
to
make
a
lot
of
connections
to
you
that,
then
it
will
not
help.
What
is
really
just
one
restriction
that,
because
here
only
Mac
to
AP
relationship
is
checked.
It
is
not
a
check
who
is
the
router,
because
the
router
everybody
could
claim
I
I'm
the
router,
and
it
means
that
era
guard
filtering
on
some
switch,
your
own,
it's
still
needed.
T
There
are
therefore,
it's
not
a
replacement
for
a
regard
next
slide,
please
what
has
changed
science
last
time.
There
were
a
few
comments,
primarily
on
the
last
ATF
and
one
comment
on
the
Alias
and
to
reflect
what
has
been
asked
in
in
the
comments
it.
The
text
has
been
changed
a
little
bit.
It
has
been
discussed
that
typically
layer
2
is
already
protected
by
encryption.
It
has
been
discussed
what
will
happen
if
it
would
be
duplicate,
MAC
address
on
the
link.
T
Somebody
will
try
to
be
duplicated,
it's
probably
will
create
flapping
and
no
no
one
will
work
anyway.
It
has
been
discussed
what
that
Mark
changes,
the
same
complexity
as
AP
change.
It
means
no,
it's
more
or
less
easy
and
some
some
small
other
comments.
It
looks
like
from
not
very
big
feedback
from
ATF
or
Alias.
It
looks
like
the
problem
is
not
so
much
interested
okay,
but
it's
still
security
problem,
for
which
we
have
Savvy
development,
which
is
deep
filter
and
on
switches.
T
We
have
initially
sand
and
we
have
after
this
HBA,
and
we
have
we
have.
We
have
many
things
before
in
the
past
when
we
were
trying
to
protect
the
link
layer
and
it's
still
still
not
protected.
For
that
reason,
it
looks
like
important
topic,
but
from
not
much
not
much
interest
yet.
T
Therefore,
I
will
be
happy
if
anybody
will
join
this
particular
draft,
especially
on
a
blockchain
site,
because
maybe
my
understanding
from
blockchain
is
not
the
best,
and
if
you
will
look
to
the
draft,
you
will
see
that
it's
a
lot
about
blockchain.
It's
a
lot
about
the
proper
calculation,
the
challenge,
the
proper
calculation
of
parameters
which
needed
for
blockchain
to
work
properly.
For
that
reason,
especially
if
somebody
is
good
on
blockchain
and
will
join
me,
I
will
be
happy,
but
anyway,
any
feedback
is
welcome.
T
F
P
P
P
Now
for
the
last
15
euros,
there
were
groups
in
the
ATF
which
have
been
working
on
how
you
do
IPv6
over
radios-
and
this
includes
many.
This
includes
raw.
This
includes
six
low
parents,
six
low
number
of
working
groups
and
those
working
groups
using
Wireless
discovered
that
the
traditional
model
that
we
had
in
mind
did
not
fit
the
reality
of
the
networks
you
could
build
with
radios.
P
Next
slide,
please!
So
if
we
look
in
more
detail,
what
all
those
groups
converge
to
is
that
the
the
link
that
IP
needs
for
wireless
is
not
a
complex
structural
with
many
nodes
on
them?
We
ended
up
building
IP
links,
which
were
always
point
to
point
and
if
you
think
about
for
a
second
about
what
a
link
local
address
is
on
the
radio,
what
what
that
should
be
and
how
you
would
do
that
I
mean
you,
take
your
radio
with
you
and
you
go
across
the
world.
When
do
you
do
that?
P
How
long
can
you
expect
that
your
address
is
unique?
So
what
is
this
link
on
which
you
configure
your
link,
local
address
and
for
which
you
can
expect
it's
going
to
stay
unique,
and
we
ended
up
figuring
out
that
the
link
has
to
be
a
handshake,
an
agreement
between
two
nodes
and
within
that
agreement
between
two
nodes,
then
your
link
Loco,
can
be
confirmed
as
being
unique,
and
so
that's
why
we
built
the
the
IP
links.
P
P
P
Please
and
the
same
discussion
happened
for
what
is
a
subnet
used
to
be
that
your
subnet
was
your
broadcast
domain,
so
I
have
the
switch
fabric,
I
run
spending
tree
or
l2r
and
and
I
can
basically
broadcast
to
a
certain
number
of
nodes,
and
my
Subnet
will
be
this
set
of
nodes
or
maybe
a
subset
of
this
set
of
nodes,
so
it
will
be
contained
within
the
broadcast
domain
and
then
again,
this
is
really
damaging
when
we
want
to
build
a
radio
network
and
we
do,
we
can
build
networks
which
tons
of
our
kilometers
and
have
thousands
of
nodes,
and
we
do
build
those
networks.
P
There
are
thousands
of
nodes
in
them
and
certainly
they
are
not
contained
within
a
single
broadcast
domain.
So
we
we
basically
build
three
sorts
of
topologies
on
which
we
can
apply
a
subnet.
The
simplest
is
the
same
as
your
IP
Link.
So
it's
going
to
be
a
pair
of
nodes
and
let's
decide
that
we
have
this
prefix
and
it's
let's
form
this
prefix
about
this
subnet
or
if
you
look
at
Network
like
Bluetooth
energy,
for
instance,
then
it
makes
sense
to
Define.
That
coordinator
is
a
hub
and
provides
the
prefix.
P
And
then
all
the
devices
attached
to
this
coordinator
will
build
autoconf
or
whatever
notarize
from
the
prefix
of
that
Hub.
So
you
build
the
Hub
and
spoke,
and
the
router
is
typically
The
Hub
and
now,
when
building
larger
Fabrics
larger
networks,
we
build
what
we
you
know
so-called
mesh
and
with
ripple
it's
it's
a
rot
of
our
mesh.
P
We
route
over
this
mesh-
and
you
see
the
links-
are
again
point
to
point
connection
between
devices
and
the
subnet
is
more
or
less
administratively
decided
all
the
nodes
which
form
addresses
from
the
same
mesh
prefix
and
participate
to
the
same
routing
inside
that
mesh
will
be
known
to
the
same
prefix,
and
this
allows
to
administratively
decide
the
size
of
your
of
your
subnet.
What
the
subnet
will
be
Etc.
P
So
you,
you
gain
a
full
freedom
of
deploying
your
subnet
over
any
topology,
including
overlays,
next
slide,
so
to
build
this
IPv6
NDS
was
built
25
years
ago,
as
a
number
of
I
would
say
unmet
expectation.
The
First
full
and
met
expectation
is
that
ND
was
defined
for
a
network
where
broadcast
was
cheap
and
reliable,
and
we
know
that
even
though,
for
instance,
a
2.11
with
the
BSS
can
emulate
a
broadcast,
it's
neither
labeled,
not
cheap,
then
the
other
expectation
is
is
that
the
links
are
transitive
effect
and
CB
and
B
can
CC.
P
Then
a
can
CC,
and
when
you
build
a
radio
mesh.
Clearly
at
some
point,
your
broadcast
domain,
which
your
radio
can
reach,
cannot
get
to
any
of
our
devices
for
which
you
need
to
relay.
So
this
is
why,
when
we
build
money
or
iot
iot
networks,
we
really
we
relay
at
least
three.
We
wrote
this
allows
us
to
save
a
lot
of
energy
because
we
don't
rely
on
broadcast
anymore
and
that
also
allows
us
to
administratively
Define.
You
know
what
the
subnet
will
be,
so
we
we
gain
a
full
freedom
of
defining.
P
What
IPv6
will
see,
regardless
of
what
ipv2
layer
2
gives
us
now?
There
are
a
number
of
other
mismatches,
but
I
don't
have
that
much
time
next
slide,
please.
So,
just
for
the
sake
of
of
showing
this
room,
we
we
have
done
a
number
of
rfcs
into
those
are
working
groups.
I
have
a
list
later,
which
basically
tell
us
how
we
could
do
neighbor
Discovery
in
a
more
deterministic
fashion,
so
we
know
better
which
addresses
are
used
where,
and
you
know
in
many
enrolled
the
the
addresses
move
in
Wi-Fi
as
well.
P
So
we
want
to
be
able
to
know
what
is
the
latest
location
deterministically
and
the
more
we
want
to
have
many
many
addresses
or
devices
the
more.
We
need
to
know
precisely
the
ones
that
are
still
in
use
and
where
they
are,
and
if
we
know
deterministically
which
address
is
where
then
we
can
establish
routing
between
well
the
small
routers
which
will
form
your
subnet.
P
So
we
we
have
defined
with
RFC
8505
what
we
call
stateful
address
of
the
configuration
or
Wireless
ND,
and
that
allows
basically
the
host
to
declare
Etc
to
the
router
without
any
broadcast,
and
you
know
that
probably
the
biggest
slide
that's
still
around
is
the
fact
that
IPv6
doesn't
use
broadcast
IPv6
uses
more
broadcast
than
ipv4
now.
The
second
thing
we
did
is
the
capability
to
interrupt
between
registration
in
854405
and
a
classical
ND,
but
what
that
we
call
backbone-
and
this
is
pretty
much
the
flow
that
that
is
Illustrated
here.
P
If
you
couple
the
registration
and
all
that,
then
you
can
connect
to
the
network
quite
rapidly
and
as
you
build
this,
you
realize
that,
for
instance,
in
this
case,
the
six
cylinder
station
can
be
on
a
network,
a
physical
Network,
which
is
very
different
from
the
backbone
or
it
could
be
on
the
same
network.
I
mean
this
really
doesn't
matter
or
it
could
be
on
a
network
where
the
MAC
address
is
not
breachable
with
the
the
backbone.
P
P
P
That's
the
answer
of
what
what
does
sand
become
in
this
world
and
if
you
start
thinking
registration,
where
the
host
can
declare
its
addresses
to
the
routers,
then
it
can
also
provide
some
kind
of
cryptographic
token
and
now,
if,
if
the
routers
share
that
information,
then
only
a
host
which
knows
how
to
build
and
can
prove
the
ownership
of
that
token,
if
only
those
hosts
can
actually
use
Services
of
any
router
on
your
pref
in
your
subnet,
then
you
can
effectively
defend
your
addresses
against
impersonation
and
and
don't
do
sound,
do
Savvy.
P
Basically,
so
8928
is
Savvy,
made
simple
and
sent
me
into
page
simple,
because
again
the
registration
allows
it
to
be
simple.
That's
by
changing
the
product
of
how
you
use
ND.
You
also
make
it's
securing
much
simpler
and
date.
9
to
9
is
pretty
much
the
ND
proxy
would
I
try
to
I-545
a
host
will
tell
the
router,
hey
I
have
this
address,
but
it
will
also
tell
the
router
hey.
You
know
if
there
is
some
rotting
or
some
operation
above
you
do
it.
P
For
me,
please
ensure
that
you
give
me
a
reachability
and
if
the
router
above
is
effectively
an
ND
proxy,
for
instance
a
Wi-Fi
access
point
doing
any
proxy,
then
this
is
the
signal
to
the
proxy
that
it
should
proxy
for
that
address.
Now
the
same
in
505
works
with
multiple
routing
protocols.
It's
used
for
Rift,
it's
used
for
Ripple,
obviously,
and
there
is
also
a
draft
for
evpn.
P
So
it's
basically
the
protocol
independent
fashion
for
a
host
to
tell
the
router
hey
I.
Have
this
address.
Unless
there
is
a
prime,
it's
my
address,
please,
you
know
do
whatever
is
needed
to
get
it
routed
to
me,
and
then
there
is
new
work
where
we
actually
extend
this
for
not
only
registering
unicast
addresses
but
also
multicast
addresses
for
those
who
are
first
in
MLD.
You
know
that
MLD
also
requires
broadcast.
So
MLD
also
is:
is
low.
P
Power
is
high
power
having
its
low
power
unfriendly,
because
it
requires
the
host
to
be
awake
all
the
time
which
is
killing
your
energy.
Basically,
so
we
are,
we
are
extending
to
multicast,
and
now
we
are
also
extending
to
prefix
it's
something.
We
discussed
two
I
atfs
ago
at
six
low
and
we'll
discuss
that
snack
as
well.
P
P
Last
but
not
least,
we
have
this
unicast
lookup.
So
as
soon
as
the
routers
know,
deterministically,
where
each
IPv6
addresses
in
the
in
the
subnet,
then
why
would
you
broadcast
an
address?
Lookup
then
again,
anything
broadcast,
including
lookup,
means
that
the
the
receiver
must
be
awake.
If
you
want
to
save
energy,
you
must
have
the
right
to
sleep.
P
The
unicast
lookup
draft
says
Hey.
The
routers
know
where
the
address
is
just
as
the
routers
don't
ask,
broadcast
the
whole
fabric,
which
is
killing
evpn,
which
is
killing
your
wireless
Etc.
Just
do
a
lookup
to
this
abstract
construct
that
we
call
6lbr,
6
lbr
in
practice
in
six
slope
and
ND
is
an
abstract
thing.
It
doesn't
have
to
be
a
server,
it
could
be
seen
as
a
DHCP
server,
but
it
can
also
be
fully
distributed
with
evpn
or
it
can
be
partially
distributed
with
proxy
and
D.
P
H
So
you
have
the
slide
earlier,
where
you
had
the
three
models
with
point-to-point
classical
broadcast
domain
and
dimesh
Network
in
in
that
mesh
Network
scenario.
H
What
is
the
actual
benefit
of
considering
this
a
subnet
I.E
if
you're
looking
at,
for
example,
RC
7404,
which
describes
operating
without
any
Global
addresses
between
routers?
That's
pretty
much
the
same
situation
like
you're
trying
to
have
the
64
on
the
mesh
with
the
addresses
for
the
hosts?
Why
not
consider
it
a
128
on
each
host,
I.
P
Can
tell
you
where
it's
deployed
I?
Guess
it's,
it's
all
a
matter
of
deployment,
so
this
is
deployed
exactly
like
that
in
the
smart
grid,
where
a
single
of
the
subnets
is
Thousands
to
tens
of
thousands
of
nodes
and
provisionally
speaking,
we
don't
want
to
go
ahead
and
give
them
all.
How
do
you
just
go
to
those
iot
devices
and
give
them
a
different
prefix?
Why
should
we.
H
It
you
don't
need
to
give
them
a
prefix
I
think
you
can
actually
use
the
regular
prefix
advertisements
and
just
not
have
the
prefix
be
on
link.
So.
P
H
P
Okay,
so
so
the
piece
that
we
are
discussing
here
is
how
the
host
will
so
it's
a
rotting,
it's
rotted
fabric
right,
so
it's
rotting
inside
the
subnet
so
far
so
good.
So
another
question
is
you've,
got
hosts
everywhere
in
that
subnet
and
it's
radio,
meaning
that
at
some
point
of
time
the
IP
links
that
you
can
form
are
this
and
next.
Second,
they
are
different
because
the
radio
reachability
has
changed.
P
B
R
Around
security
I
mean
you
really
don't
want
to
use
ND
for
this.
It
doesn't
have
updates
you
like
you're,
basically
trying
to
build
Dynamic
subnets
with
I
mean
if
you're
trying
to
build
Dynamic
subnets,
where,
like
the
the
set
of
nodes
on
any
subnet,
is
like
dynamically
updatable
and
D
is
just
the
wrong
protocol.
You
started
off
saying
you
know
that
we
have
like.
We
basically
have
this
concept
of
subnet,
that's
stuck
in
ipv4,
it's
not
really
even
stuck
in
ipv4.
It's
like
built
for
very
simple
links.
R
It's
basically
intended
to
say:
okay,
is
this
local
or
is
it
not
but,
like
David
said,
basically,
as
soon
as
you
get
to
something
relatively
complicated,
you
have
to
do
everything
off
link,
so
it
sounds
like
you're
like
at
that
point.
I
think
that
the
problem
that
you
have
left
once
you've
marked
everything
out
of
link
is
how
do
the
host
communicate
to
the
routers,
where
they
are
perfectly
true,
but
that's
a
lot
easier
than
than
doing
all
of
this
ND
stuff.
You
can
do
that
in
a
lot
of
other
ways.
P
The
problem
is
today
with
the
NDS:
it
stays
and
even
with
the
hcp,
the
router
doesn't
have
a
clear
picture
of
which
addresses
are
out
there
and
where
they
are
for
the
last
time.
So
there
are
all
sorts
of
of
hooks
of
Tricks
which
are
being
played
depending
on
the
environment.
Because
of
this
lack
of
clear
interaction
between
the
host
and
the
router,
then
you
may
call
it
ND.
U
So
the
document
as
written
right
now
actually
proposes
adding
this
flag
to
the
ra
Flags
extension
option.
I!
Don't
really
know
that
that's
necessary
because
there
are
six
flag,
that's
still
available
in
the
ra
header,
but
either
way.
B
U
Either
way,
the
idea
is
to
add
a
new
flag
next
slide,
and,
let's
see,
is
that
yeah
here
we
go
so
so.
The
idea
of
this
flag
is
basically
to
signal
that
the
Aria
is
coming
from
a
stub
router
as
opposed
to
an
infrastructure
router.
For
those
who
don't
know,
the
snack
working
group
is
working
on
this
new
thing
called
a
stub
router
that
connects
to
the
infrastructure,
really
without
you
know,
needing
permission
or
cooperation
from
the
infrastructure
to
enable
like
an
iot
Network,
to
be
accessible
by
devices
on
the
infrastructure.
U
In
order
to
do
that,
it
has
to
send
Ras,
but
we
don't
want
it
to
look
to
the
infrastructure
like
like
its
infrastructure.
We
want,
we
want
it
to
be
distinguishable
from
infrastructure,
so
having
a
bid
in
the
router
advertisement.
That
says
this
is
a
stub
Network
and
not
an
infrastructure
network
is
helpful.
U
There's
a
couple
reasons
why
it's
helpful
one
is
that
it
allows
stub
routers
to
notice
if
there
is
an
infrastructure
prefix
being
advertised
on
the
link
and
not
advertise
a
prefix.
So,
in
order
to
do
IPv6
communication,
you
need
to
advertise
a
prefix
on
the
link.
That's
that's
configurable
and
if
there's
already
a
prefix
on
the
link,
then
you
would
prefer
to
use
that
prefix.
U
So
this
is
basically
just
to
promote
cooperation
and
avoid
publishing
extra
prefixes
on
the
link
next
slide,
and
the
other
benefit
is
that
you
might
have
a
situation
where
you
have
a
stub
router
or
a
sub
Network.
Remember
a
sub
Network!
For
those
who
don't
know
a
sub
network
is
like
a
stub.
It's
a
leaf.
It's
not
supposed
to
have
any
further
networks
as
you're
not
supposed
to
do
routing
across
it
or
anything
like
that.
U
So
it'd
be
nice
to
be
able
to
tell
when
you're
plugged
into
and
when
a
stub
router
is
plugged
into
a
network
to
be
able
to
tell
whether
it's
an
infrastructure,
Network
or
a
stub
Network
easy
way
to
do.
That
is
to
look
at
the
router
advertisements.
So
basically,
this
allows
us
to
use
the
bit
the
stub
router
bit
to
tell
that
we're
being
plugged
into
a
stub
Network
and
refuse
to
try
to
use
it
as
Transit.
U
So
that's
pretty
much
the
goal
next
slide.
Yeah
questions.
R
I
think
this
is
useful,
but
I
don't
understand
why
it's
a
property,
the
router
itself,
as
opposed
to
like,
let's
say
the
Pio
and
the
roots
that
it
advertises
right
because
it
yeah
I
mean
what
you
want
to
do.
Is
you
want
to
basically
withdraw
the
Pio
and
you
want
to
with,
or
you
want
hosts,
maybe
to
ignore
the
Pio
and
the
Rio
that
you
get.
R
U
Whole
yeah
I
mean
that's
a
good
question,
so
let
me
think
about
that.
F
U
I
mean
I
would
say,
I
would
say,
that's
a
good
question.
I
I,
don't
know
the
correct
answer
to
that
off
the
top
of
my
head,
and
maybe
that
is
the
right
thing
to
do
so.
We
should
just
talk
about
that.
Basically,
what
I'm
trying
to
do
here
is
actually
figure
out
a.
Is
there
any
objection
to
doing
this
and
B?
U
Is
this
the
right
place
to
do
it?
I
mean
we
could
do
this
in
snack?
It's
not
in
the
charter
right
now,
but
in
principle
it
could
be
I
think
this
working
group
is
certainly
more
qualified
to
to
think
about
the
question,
but
on
the
other
hand,
it's
a
really
trivial
question,
we're
just
adding
a
bid,
so
you
know
I'm
perfectly
happy
yeah
yeah,
that's
it
yeah.
So
I
I'd
like
to
see
this
adopted
either
here
or
to
be
instructed
to
adopt
it
elsewhere.
T
Hello,
this
particular
flag
looks
like
a
small
piece
of
a
big
solution
and
it's
not
possible
to
understand
the
overall
in
this
solution
and
then
it's
not
possible
to
to
decide.
Is
this
flag,
useful
or
not,
because
it
looks
like
a
small
piece
in
the
topology
which
you
have
shown
on
the
previous
slide?
The
internet
predicts
should
be
somehow
splitted
distributed
through
the
side
in
its
home
network
control
protocol
or
something
like
this
again
or
maybe
httpg
or
whatever
I.
Don't
understand
how
it's
possible
to
judge
about
this
without
looking
to
whole
solution.
T
B
That's
a
little
bit
of
the
I
mean
the
discussion
we
had
at
the
beginning
this
spring,
in
some
sense,
I.
Think
for
us
to
do
it
here.
We
need
to
hear
from
snack
that
this
you
would
like
to
have
this
from
us
or
something
like
that.
Okay,
I,
don't
think
we
should
just
take
it
on
before
that
happens.
Okay,.
U
I
So
I
think
one
of
the
things.
The
first
thing
you
said
is
like
hey,
there's
six
bits
left
they're,
not
there's
only
two
bits
left
just
to
like.
So
that's
why
I
think
the
51,
so
six
bits
have
been
taken
in
the
ra,
so
m
o
mobile
IP.
It
was
it
didn't,
update
the
right
RFC,
so
we
had
an
average
problem
back
in
the
day.
I
Yeah
six
bits
are
gone
for
preferences
right,
like
and
so
on,
so
so
I
think
that's
kind
of
why
it
needs
to
go
in
the
option
so
that
that
I
just
want
to
clarify
that
and
I
think
like
snack,
would
be
a
good
place
to
do
it
like
with
six-man
review.
To
do
this
and
I
have
no
particular
preference
with
the
Pio
or
here
like
in
I,
think
this
is
easier,
probably
for
lower
end
routers,
which
might
be
the
stub
routers
to
process.
I
Maybe
it's
it's
going
to
be
faster
than
going
through
a
bunch
of
pios,
because
then
you
have
to
say
which
Pio
goes
in.
If
you
have
multiple
prefixes
so
and
what,
if
the
conflict
and
so
on
in
this
one,
it
becomes
clear
that
it's
coming
from
an
infrastructure
order,
so
I'm
supportive
of
putting
in
the
ra
Flags
instead
of
pio
but
I,
don't
really
care
that
much
okay.
U
I
My
point
was
not
about
the
stub
router
is
the
infrastructure?
Router
is
advertising
it
right,
like
you
need.
I
I
understand
but
you're
processing
the
Pio,
so
you
need
to
put
it
in
Pio
logic
right.
The
sublotter
can
get
a
Pio
from
an
infrastructure
order.
It
still
doesn't
know
where
it's
coming
from.
So
it
needs
to
process
the
Pio
and
expect
this
flag
there
so
which
I
don't
want
to
do
right
like
because
you
don't
have
to
go
through
all
the
pios
coming
in,
because
the
infrastructure.
U
I
Understand
but
you
don't
have
to
look
for
the
stub
router
flag.
You
don't
need
to
know
if
it's
just
you
need
to
know
if
it's
a
step,
router
or
not
right,
because
your
idea
is
like
you
keep
doing
this
until
you
realize
there's
an
infrastructure
router.
That's
why
the
suborder
flag?
Is
there
right?
Okay,
so
if
you
put
in
the
Pio,
you
need
to
process
multiple
pios,
but
we
can
take
this
further
offline,
but
I
think
there's
a
better
way
of
doing
this.
This
year.
Okay,.
G
Everything,
the
snack,
A.D
and
looks
like
it's
a
interior
interior
discussion
here.
So
basically,
we
are
not
able,
in
the
chart
of
snack
to
Define
any
Flags
yeah
just
for
processing
right.
We
can
Define
the
requirements
and
then
we
need
to
go
here
just
to
be
clear.
Yep.
A
We
are
just
on
time.
Thank
you
very
much.
Please
send
your
comments,
for
which
we
did
not
have
time
as
a
microphone
to
the
list
and
see
you
in
Yokohama.
Thank
you
very
much.