►
From YouTube: IETF110-V6OPS-20210309-1600
Description
V6OPS meeting session at IETF110
2021/03/09 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
Welcome
to
v6
ops,
so
ron
is
displaying
the
note
well,
and
so,
if
you,
if
this
is
new
to
you,
please
note.
Well,
we
have
a
a
note
taker,
that's
chuping
and
thank
you
shipping
for
for
taking
notes
for
us.
We
don't
have
a
jabber
scribe
and
I
note
that
there's
at
least
one
person
who's
following
us
by
jabber.
A
A
A
They
would
like
to
talk
about
something
that
linux
is
doing
with
the
tcpm
float.
Labels
are
the
flow
label,
ipv6
flow
labels
in
a
linux
environment,
and
then
fernando
is
going
to
talk
about
the
addressing
considerations
document
that
he's
got
up
and
which
has
been
under
discussion
so
ron
could
could
we
look
at
the
chairs
comments
slides
here?
A
A
A
A
Now
this
is
a
slide
that
I
pulled
out
of
a
deck
that
that
I
built
two
years
ago,
so
the
numbers
are
a
little
bit
out
of
date,
but
a
a
central
american
country
wanted
to
build
a
greenfield
network,
basically
as
an
enron,
and
they
had
a
proposal.
They
had
multiple
proposals
to
build
it
using
ipv4
and
they
had
at
least
one
proposal
to
build
it
as
an
ipv6
network
and
in
looking
at
the
cost
of
doing
those.
A
Building
that
network
using
ipv4
would
cost
them
multiple
tens
of
millions
of
dollars,
building
it
out
of
ipv6
cost
twenty
one
hundred
dollars
annually
as
of
two
years
ago.
It
may
have
changed
since
then
and
point
being
that
you
know
I
went
whenever
I'm
talking
with
somebody
about
ipv
sex.
They
say,
what's
the
business
case
to
me,
this
looks
amazingly
like
a
business
case.
It
costs
less
money.
You
can
save
an
awful
lot
of
money
by
running
ipv6
next
slide.
A
A
Now,
I'm
not
going
to
throw
open
the
floor
to
discussion
primarily
because
I
think
a
lot
of
this
will
come
up
about
two
talks
from
now
and
we
can
discuss
it
on
the
web
on
the
mailing
list
as
well.
But
something
I
would
like
us
to
think
about
is:
are
we
the
ietf
doing
something
wrong
in
our
discussion
of
ipv
sex
and
ipv6
deployment.
B
D
D
Slide
all
right,
thank
you,
so
motivations,
so
the
hph
options.
Header
is
a
valuable
container,
facilitating
new
services.
So
the
hop
I
have
processing
behavior
is
very
it's
very
desirable.
It's
something!
That's
you
know
that
I
think
overall,
I
think
in
the
industry
and
we're
seeing
a
lot
more.
I
think
new
features
such
as
second
routing
and
others
that
are
now
starting,
you
know
or
other
I
guess
flavors.
D
D
Current
operator,
networks
and
and
the
problem
is,
operators
have
have
been
really
reluctant
to
actually
allow
hph
into
the
network,
and
just
just
with
with
that
of
separation,
of
control,
plane
and
data
plane
and
having
traffic
that
should
be
processed
in
the
forwarding
path
having
to
be
punted
to
the
control
plane
and
that
impact
of
of
of
traffic
you
know
being
forwarded
and
having
to
get
rate
limited
or
pushed
down
to
the
control
plane,
possibly
impacting
the
management
plane.
So
that
has
been
a
worry
for
operators.
D
D
So
the
main
purpose
here
is
breaking
the
endless
cycle.
That's
resulted
in
the
hbas,
you
know
really
becoming
a
dos
vector
so
that
that's
an
area
where
you
have
you
have
h.
You
have
an
hbh
header,
you
know
valid,
you
know
options,
you
know
that
are
that
are
in
a
packet
with
valid
hph
options,
but
now
because
the
hph
is,
is
a
dos
vector,
most
operators.
D
Being
reluctant
and
afraid
of
that
cross
communication
from
you
know
something
that
should
be
an
affordable
plan
now
being
put
into
the
control
plane
and
impacting
the
management
plan,
so
that
that's
just
been
a
really
historical
issue
and
now
being
able
to
develop
and
being
able
to
use
the
hbh
header.
It's
really
impacted
that
development.
D
D
So
common
implementations,
so
the
sort
of
here
the
so
the
value
of
the
next
header
field
in
the
ipv6
header,
so
the
trigger
for
the
default
processing
behavior
of
the
hph.
It's
a
common
implementation.
So
once
the
device
receives
an
ipv6
packet
with
this
next
header
field
set
to
zero,
we'll
direct
it
to
the
they'll,
be
directed
to
the
slow
path,
so
the
option
type.
D
So
the
option
type
of
each
option
will
be
examined
before
the
packet
is
sent
to
the
slow
path.
So
in
most
cases
such
processing
behavior
as
a
default
configuration
can't
be
changed.
So
that's
that's
really
good
the
general
as
soon
as
that
that
hbh
headers
is
received
with
a
type
zero.
It's
generally-
and
this
has
just
been
a
common
behavior
across
most
most
asics
fixed
function,
assets
where,
as
soon
as
that,
packet's
received
got
that
hph
option
zero.
It's
forwarded
to
the
slow
path,
historical
reasons
with
the
with
that
hph
absence.
D
We're
not
yet
well
really
well
understood
by
operators
as
well
and
and
throughout
the
industry
and
flexible,
fixed
function.
A6
performing
proprietary
functions
were
not
so
capable,
as
they
are
today
with
modern
software.
Programmable
mpus
that
can
forward
at
line
rate
in
the
fast
path
and
still
be
able
to
perform
complex
tasks
such
as
hp,
forwarding
options
processing
without
having
to
punch
the
slow
path
consequences.
D
D
Next
slide
thanks,
so
the
desired
processing
behavior
so
with
the
control
plane
should
be
protected
against
the
undesirable
traffic.
So
with
the
hph
options
that
are
not
supported
to
be
processed
by
the
control,
pane
should
not
be
sent
to
the
control
plane
potentially
causing
the
dos
attack.
So
just
kind
of,
I
guess,
based
on
that,
I
guess
when
you
think
about
it,
you
have,
when
you
look
at
the
hph
options,
there's
options
that
that
are
destined
for
the
control
plane
and
then
there's
options
that
are
destined
for
the
forwarding
plane.
D
So
so
the
idea
is
behind
this
problem
statement
and
then,
and
then
also
a
possible
solution
is
decoupling
options
that
are
bound
for
the
control
plane
to
to
remain
processed
by
the
control
plane,
but
options
that
are
not
destined
for
the
forward
plane.
It
really
should
stay
in
the
forwarding
plane,
but
not
should
not
be
processed
by
the
control
plane
should
should.
I
should
be,
should
be
segregated
and
actually
treat
it
differently.
D
So
the
hph
options
header
should
not
be,
should
not
be
directed
sent
to
the
control
plane,
but
the
packages
from
steve,
since
these
options
may
not
be
aimed
for
the
controller,
and
so
that's
that's
really.
The
kind
of
big
big
concept,
an
idea.
It's
really
that
separation,
decoupling
options
that
are
hph
options
that
are
control
plane,
destined
versus
hbh
options
that
are
really
destined
for
the
forwarding
plane
that
could
be
processed
in
the
forwarding
plane
source
nodes
should
not
enable
hbh
options
that
exceed
the
maximum
length
of
hph
options.
D
So
the
idea
is
basically
better
to
separate
the
two
option:
types
that
are
supposed
to
be
processed
by
the
control,
plane
and
forwarding
plane
respectively,
so
breaking
them
into
two
buckets
desired.
Processing
behavior
for
the
two
types
options
are
different
and
the
options
are
really
aimed
for
the
control
plan
are
better
to
be
consumed.
D
We
should
to
not
consume
forward
and
plain
resources,
and
that's
really
the
big
deal
that
why
have
them
be
processed
by
the
forwarding
plane.
Let
them
really
be
processed
by
the
control
plane
and
only
have
anything
destined
for
the
forwarding
plane
be
processed
at
line
rate
by
the
forwarded
plane.
So
new
development
should
be
compatible
with
existing
deployment.
So
that's
something
that
we,
you
know
we
want
to
be
cognizant
of
of
any
solution
that
that
we
propose,
since
the
default
configuration
of
some
devices
cannot
be
reconfigured.
D
The
update,
the
update
of
the
entire
network
cannot
be
done.
You
know
within
with
a
date,
so
it
would
take
with
any
solution
it
will.
It
will
take
time
to
to
to
progress
and
that
should
be
able
to
it's.
It
is
definitely
like
a
period
of
the
paradigm
change,
so
it'll
take
time,
even
with
any
proposal
to
move
from.
You
know
what
we
have
today
to
a
a
new
solution.
D
That's
first
step.
The
second
is
the
nodes
within
the
network,
so
the
nodes
within
the
network
updated
to
the
proposed
behavior
introducing
introduced
in
the
previous
section.
So
that's
separation
of
the
processing
behavior
of
of
hvh
options
that
are
destined
for
the
forwarding
plane
the
edge
nodes
on
the
network.
In
this
third
step,
the
edge
node
should
check
whether
the
packet
contains
an
hph
header
with
control
or
forwarding
option
packets
with
the
control
options
may
still
be
filtered
and
dropped,
while
the
taxes
and
the
forwarding
options
should
be
allowed
by
the
acl.
D
It
is
certain
that
there
there
is
no
harm
that
could
be
introduced
by
the
hph
options
to
the
nodes
and
services
that
can
be
done.
That
can
also
be
allowed
during
the
migration
stage.
The
nodes
that
they're
not
yet
updated
will
stay
with
their
existing
configuration.
So
so
so
the
overall
idea
is
really
separating
into
two
buckets.
Anything.
That's
using
the
existing
hph
option
would
would
would
be
the
control,
plane
options
and
then
anything,
that's
any
any
options
that
are
destined
for
the
forwarding
plane.
D
E
E
E
The
proposal
to
create
the
proposal
to
divide
options
into
two
classes,
control,
plane
and
forwarding
plane,
and
I
think
you
talked
about
a
proposal
to
take
to
create
two,
a
new
extension
header
type
that
also
falls
outside
of
icharter.
So
that
would
that's
something
you
know
bob
hinden
would
might
want
to
comment
on.
I
think
he's
in
the
room.
D
I
understood
we
do
have
a
draft,
that's
in
the
hbh4
hvh
forwarding,
which
is
the
new,
which
is
a
six
man.
I
think
there's
a
further
slide.
I
guess
the
next
slide
down.
That
has
the
proposal,
which
is
in
six
man,
so
this
this
draft
is
actually
really
it's
just
for
the
problem
statement
and
then
the
concept
and
then
and
then
the
the
solution
is
the
solutions
draft
is
in
the
that's.
What's
what
six
man.
D
C
Hi
so
yeah
I
mean
I've,
read
the
draft
and
it
I
just
first
I'll
disagree:
it
talks
about
two
different
types
of
options,
and
that
is
a
solution,
not
a
problem.
I'm
very
supportive
of
the
problem
statement.
Part
of
this.
I
agree
that
it
would
be
much
better
if
I
hop
options
worked
and
were
useful.
I've
proposed
one
for
path,
mtu
discovery.
There
could
be
others,
and
I
actually
have
a
draft
that
will
be
discussed
in
six
man
on
thursday.
C
So
that's
a
fairly
big
change,
but
I
think
the
notion
of
creating
another
option
container
with
hopki
hop,
is
going
to
just
make
things
more
complicated
and
will
not
solve
this
problem.
I
think
it's
going
in
the
wrong
direction.
The
draft
I
will
talk
about
tries
to
make
it
simpler
with,
but
with
the
same
goal
of
making
hopper
hub
options
usable
in
the
operational
internet.
F
Yeah
hi,
I
have
a
potentially
very
sick
question,
so
I
I
assume
for
some
reason
that
this
distinction,
this
separation
between
something
processed
and
slow
past
and
something
protest
in
fast
past.
It's
not
a
property
of
a
package.
I
would
assume
it's
the
property
of
the
router.
What
kind
of
things
it
could
process
is
the
slow
pass,
and
what
kind
of
process
is
the
fast
pass
right
and
this
could
change
over
time?
F
D
Yeah,
that's
that's
a
that's
a
good
good
point.
I
mean
I
think,
with
that
it
would
probably
it
would.
It
would
be
a
evolving
that
that,
let's
say
you
know,
let's
say
new
options
come
up
that
are
that
should
be
processed
in
the
in
the
slow
path
they
would
remain.
They
would
remain
that
are
control,
plane
options.
They
would
remain
in
the
slow
path,
but
new
options
that
do
and
it
is.
D
I
guess
it
would
be,
a
never
evolving
change
that
as
as
new
ones
come
up,
because
it's
two
separate
buckets.
So
that
is.
That
is
something
that
we
would
have
to
consider.
I
mean
that's
a
that's
a
good
point,
a
consideration
having
two
buckets
that
it's
not
gonna
all
sit
in
one
bucket
as
processed
by
the
you
know
by
the
you
know
normal
processing,
where
it's
processed
by
this
boarding
plane
and
then
and
then
forward
it
to
the
control
plane.
D
Where
now
now
it
would
now,
you
would
have
some
that
are
actually
in
the
forwarding
plane
and
some
some
you
know,
processed
by
the
control
plane.
I
think
the
one
way
to
look
one
way
to
look
at
it,
though,
is,
is
that
if
you
have
with
these
two
buckets,
if
you
have
options
that
are,
let's
say
existing
options
and
anything
new,
they
would
stay
like
stuff.
D
They
would
state
status
quo
that
there
would
be
no
change,
but
what
would
actually
change
is
anything
new
that
comes
about
that
actually
requires
line
rate,
processing
and
processing
in
the
fast
path,
and
that's
really
the
idea
that
keep
status
quo,
anything
that
requires
control
plane
and
that
would
be
like
legacy
anything
that
exists
today.
That's
control,
plane
and
anything
that
new
that
comes
up
would
stay,
as
is
it
wouldn't
change.
D
A
Let
me
make
a
suggestion
that
I
think
would
clarify
this
particular
discussion,
and
that
is
please
ditch
the
words
fast
path
and
slow
path.
Because
that's
not
the
question.
The
question
is
forwarding
plane
versus
control
plane
and
if
you
make
that
clear,
then
this
discussion
becomes
an
awful
lot
simpler.
D
D
You
know,
as
far
as
with
this
draft
and
work
group
adoption,
what
are
your?
What
are
your
thoughts
as
far
as
the
problem
statements
as
as
you
had
stated,
I
think
this
draft
really.
It
should
be
devoid
of
the
solution.
So
maybe
just
really
for
this,
I
think
discussion
really
focusing
really
just
on
the
problem.
Statement
really
makes
sense
as
as
this,
this
draft
and
sick
and
v6
ops
is
really
the
problem
and
understanding
the
problem
and
and
consensus
that
this
is
the
problem
that
we
want
to
that.
A
Well,
yeah,
so
looking
at
the
charter
as
ron
points
out,
the
charter
allows
us
to
develop
problem
statements
and
send
them
off
to
other
working
groups,
six
men
being
an
example
and
allows
us
to
comment
on
things,
give
an
operational
viewpoint
on
things
that
are
discussed
in
other
working
groups,
and
so
this
draft
from
a
problem
statement
perspective.
Does
that
and
that's
good?
E
I
would
agree
that
we
do
have
a
real
problem.
We
have
so
many
proposals
in
which
we
need
a
few
more
bits
in
the
ipv6
header.
The
right
way
to
do
that
is
to
use
the
hop
by
hop
extension,
but
because
hop
by
hop
extension
isn't
a
viable
option,
we're
finding
you
know,
ways
to
shoehorn
it
in
the
flow
label
or
shoehorn
it.
You
know
someplace
else,
so
we
do
have
a
real
problem.
We
really
need
hph
back
well.
This
is
by
the
way,
I'm
speaking
as
an
individual
contributor.
E
D
Here
understood,
I
understood
so
well,
so
we
can
do
that.
Update,
update
the
draft
and
really
make
it
completely
devoid
of
a
solution
and
then
and
then
take
it
to
the
mailing
list
to
review,
and
I
think
that's
really
the
focus
so
and
as
far
as
the
solutions,
as
you
said,
ron
and
fred,
we
can
take
that
that's
really
on
six
man,
but
that's
really.
It's
completely
separate
from
really
this
right
now.
D
Really
the
main
focus
is
the
problem
statement,
which
is,
it
is
a
definitely
a
real
real
problem
and
being
able
to
really
leverage
the
hph
option,
which,
as
I
got,
operators
and
there's
so
many
use
cases
that
that
could
really
take
advantage
of
this.
So
it's
definitely
a
problem
that
that
needs
to
be
solved
so
appreciate
the
feedback.
G
Yeah,
I
I
think
what
I
wanted
to
say
is
talked
about,
and
I
just
want
to
confirm
that
we
share
the
same
goal.
As
bob
said,
we
want
to
make
the
hub
hub
really
usable
for
the
operators
and
because
a
lot
of
new
features
really
depend
on
it,
for
example,
the
past
mtu,
and
currently
we
have
two
drafts,
the
winding
six-man
and
the
other
in
the
v6
ops.
The
reason
we
have
this
draft
in
v6
ops
is
is
about
we.
G
G
H
Thank
you,
yeah,
I'm
not
sure
if
the
mic
line
was
closed.
If
so,
I
will
sit
back
down.
If
not,
oh
speaking,
with
no
hats
to
me,
it
seems
that
once
all
the
sort
of
solution
is
removed
from
this,
the
only
thing
you
end
up
with
basically
reduces
down
to
it
sure
would
be
nice
if
my
hop
options
worked
and
the
reason
that
I
hop
options
don't
currently
work
isn't
that
vendors
are
inherently
evil.
H
Although
some
might
be
it's
because
it's
hard
to
implement
a
lot
of
this
in
hardware,
and
you
don't
really
know
ahead
of
time
what
routers
along
the
path
might
have
done.
So
so
there's
also
it's
really
hard
without
knowing
all
of
the
vendor
implementation
details
to
be
able
to
predict
what
will
actually
work
correctly
in
the
forwarding,
plane
or
fast
path,
whatever
you
want
to
call
it.
So
I
don't
entirely
understand
how
anything's
going
to
work
with
this
other
than
saying
this
new
thing
which
I'm
writing.
H
I
really
really
really
want
to
work
on
the
forwarding
plane
and
I
certainly
hope
it
does.
I
don't
think
when
any
of
the
current
hop
by
hop
options
were
created,
the
desire
or
plan
was
that
they
don't
work
properly
because
they
get
bumped
to
the
control
plane.
So
I
don't
really
see
how
this
is
going
to
change
anything
other
than
sort
of
hoping
or
wanting
a
pony.
D
Thanks
warren
for
your
feedback-
I
you
know,
I
think
you
know
with
this-
would
be
problem
statement.
I
think
we're
gonna.
You
know,
as
a
shipping
mentioned,
I
think,
and
and
the
feedback
from
ron
and
fred
we'll
focus
on
the
problem
statement
and
really
the
problem,
which
is
definitely
a
issue
to
be
able
to
use
the
hbh
option
and
make
it
make
it
really
viable.
I
think,
to
get
from
like
point
a
to
point
b
is
not
easy
and
it's.
D
D
That
said
in
stone
that
the
work
group
and
everyone
agrees
on
the
problem,
then
then
it's
really
a
matter
of
you
know
like,
as
bob
has
his
his
draft
with
you
know,
an
idea
with
hbh
and
that
you
know
how
we
can
make
it
viable
with
just
with
a
single
hb
option,
which,
which
is
I
mean?
You
know,
I
really
you
know.
I
mean
it's
great,
that
bob
had
come
up
with
that.
That
idea.
I
D
Then
the
idea
that
we
have
with
the
solution
trap
that's
another,
and
I
think
you
know
any
one
of
those
ideas
that
anything
that
can
really
make
hvh
viable.
I
mean
we're
all
we're
all
for
it,
because
it
is
something
that
really
the
operators
within
the
industry
really
want
to
be
able
to
leverage
and
not
having
a
path
toward
the
solution.
I
mean
that
that
is
a
problem,
so
we're
open
to
any
and
all
solutions
that
can
now
solve
the
problem.
D
D
C
Yeah,
so
I'm
I
also,
I
agree
with
a
lot
of
things
that
warren
said
and
you
know
so.
I
had
two
thoughts
I
mean
we
are
going
to
have.
I
mean
if
we
get
something
that
works
and
then
we're
going
to
be
have
to
be
fairly
careful
about
what
we
allow
to
be
defined
for
a
new
for
new
hop
by
hop
options.
I
don't
actually
know
how
to
do
that.
C
So
that's
going
to
be
because
you
can
obviously
some
you
know
you
may
look
at
an
existing
one
and
that's
possible
to
do
in
the
forwarding
path.
Yeah
I'll
call
it
the
fast
path,
but
I
could
easily
imagine
defining
new
things
that
aren't,
or
at
least
not
currently
the
the
other
thing
before
six
man
goes
off
and
does
pushes
something
through
the
process
we're
going
to
have
to
have.
C
A
E
Okay,
thank
you
bob
thank
you.
Fred
may
I
jump
in
for
a
second
sure
go
ahead.
Okay,
one
quick
last
comment:
arguing
with
warren
a
little
bit
a
couple
years
ago.
I
would
have
totally
agreed
with
what
you
said,
but
I
think
things
have
changed
two
things.
First,
asics
have
become
more
capable,
so
it
will
be
possible
to
process
some,
but
not
all
of
the
hop
by
hop
options
we
can
think
of.
The
other
thing
is
we're
seeing
more
and
more
requests
to
repurpose
fields
in
the
base.
Ipv6
header.
A
G
G
D
D
D
I
I
On
the
other
hand,
I
would
like
also
to
provide
suggestions
on
how
to
improve
the
current
ipv6
deployment
strategies
and
for
that
trying
to
let's
say,
partially
answered
to
the
question
posed
by
fred.
At
the
beginning
of
our
session,
we
have
inserted
a
part
in
the
draft
named
call
for
action
to
stimulate
further
investigations
on
what
are
still
considered
the
open
points
related
to
ipv6
adoption
and
to
suggest
waves
to
move
forward.
I
Some
incentives
are
also
discussed
in
our
draft
and
thanks
to
the
feedback
we
got
from
the
main
list.
We
have
also
started
to
consider,
let's
say
adding
some
text.
Some
considerations
on
ipv4
exhaustion,
so
this
is
the
current
status
we
can
move
to
the
next
slide,
please,
where
we
show
the
differences
from
version
one.
So
we
presented
our
draft
before
itf
109..
I
I
Okay,
so
some
updated
numbers
on
ipv6.
You
find
all
the
references
in
our
draft,
but
let
me
mention
ethnic
because
we
gather
a
lot
of
the
pieces
of
information
that
we
have
reported
here
in
our
tables.
So,
first,
where
do
we
stand
with
the
adoption
of
ipv6?
The
number
of
estimated
ipv6
users
reached
1.2
billion
at
the
end
of
the
last
year,
and
I
would
say
worth
noticing
is
the
compound
annual
growth
rate,
which
is
slightly
above
40.
I
If
we
consider
the
period
from
end
of
2016
to
end
of
2020.,
the
ipv6
allocations
also
grew
the
so
you
see
the
different
numbers
related
to
the
registries
described
in
the
second
table
and
again
it's
interesting
to
note
that,
despite
the
drop
in
the
ripe
region,
which
is
described
in
the
pen
ultimate
row
in
the
second
table,
the
ipv6
allocations
have
grown
quite
a
lot.
And
if
you
compare
the
two
address,
families
in
the
third
table,
ipv6
has
grown
more
than
ipv4,
and
this
is
also
represented
by
the
last
table.
I
I
I
I
The
third
pie
is
related
to
the
technologies
to
be
adopted
in
the
mobile
space,
and
you
see
that
the
favored
technologies
are
mainly
dual
sec
and
the
x-slot
and
the
reason
for
moving
to
ipv6
in,
I
would
say
almost
all
the
answers
is
related
to
the
lack
of
ip4
addresses
and
I
would
also
add,
probably
an
increased
attention
to
ipv4
depletion,
which
is
a
good
sign.
I
will
say
next
slide.
Please.
I
I
I
I
I
So
looking
at
the
numbers,
we
have
probably
around
50
slash
8
or
50
class,
a
available
which
are
not
advertised
today
on
the
internet.
So
there
is
a
question
here.
What's
the
reason
for
that,
on
the
one
hand,
that
seems
good
for
ipv6,
probably
it's
good
or
better
could
be
explained
as
a
sign
that
since
ipv6
is
used
more
than
before,
that
has
freed
up
more
ipv4
addresses,
but
look
at
the
article.houston.
I
Also.
Let's
say
he
provides
another
possible
explanation
which
could
be
related
to
an
increased
use
of
network
address
translation.
So
if
so,
clearly
there
could
be
an
impact
on
the
deployment
of
ipv6
that
could
be
further
delayed.
Clearly,
more
investigations
are
needed
here
next
slide,
please,
and
we
are
approaching
the
section
named
code
for
action.
I
I
We
added,
let's
say
more
text
for
cloud
providers
and
data
centers.
We
have
already
mentioned
that
ipv6
is
widely
adopted.
There
is
one
point,
though:
cloud
providers
are
also
active
in
gathering
ipv4
addresses,
probably
to
answer
their
business
needs
to
provide
connectivity
for
enterprises,
so
there
may
be,
let's
say,
an
impact.
One
day
the
day
we
will
approach
a
real
exhaustion
of
ipv4
addresses.
I
I
I
But
once
again
there
are
issues
to
be
investigated,
and
then
we
have
a
final
section
on
government
and
regulators
and
in
dealing
with
this
topic,
we
try
to
summarize
our
findings
with
a
motto
stimulate
if
you
can
and
regulate.
If
you
must
why
that,
because
we
have
looked
at
some
countries,
mainly
the
european
union
area,
where
we
have
some
countries
where
the
local
authorities,
the
local
regulators,
did
a
good
job
in
supporting
ipv6.
I
So
we
have
examples
in
belgium,
france
and
germany,
which
are
quite
ahead
of
the
other
countries
in
terms
of
ipv6
adoption
and
a
good
example,
and
I'm
going
to
close.
My
presentation
here
comes
from
arsepe,
which
is
the
french
national
regulator
that
mandated
the
obligation
for
the
operators
awarded
with
a
5g
license
the
the
obligation
to
implement
to
support
ipv6.
I
I
Next
steps,
so
for
sure
we
are
open
to
listen
to
the
community.
If
there
is
anything
missing,
we
are
available
to
consider
more
topics,
try
to
put
more
considerations
in
favor
of
ipv6
for
sure
and
I'm
echoing
what
fred
suggested
at
the
beginning
of
the
sessions
ipv4
exhaustion
could
be
also
debated.
I
think
it's
the
hot
topic
that
we
have
to
deal
with
and
I'm
pretty
sure
that
more
incentives
could
be
added
to
the
draft
and
more
could
be
also
included
in
the
discussions.
I
A
E
Fred,
could
you
put
me
in
the
queue
yeah?
Well
go
ahead:
okay,
no!
Hats
on
a
couple
questions,
a
couple
things
that
would
motivate
the
deployment
of
ipv6
is
an
increase
in
the
price
of
ipv4
addresses
and
an
emergence
of
a
part
of
the
internet
that
is
ipv6
only
have
we
seen
a
steady
increase
in
the
price
of
ipv4
addresses
and
do
we
see
any
ipv6
only
islands
of
the
internet,
yet.
A
A
We
have
seen
an
increase
in
the
price
of
an
ipv4
address,
and
you
know
geo
that
spoke
to
us
last
month
or
at
the
last
meeting,
talked
about
having
a
number
of
different
services
up
all,
except
one
were
ipv6
only
so
yes
there's
at
least
that
one
island
of
ipv6
only
capabilities-
and
I
believe
jen-
might
tell
you
that
within
her
company
at
least
part
of
it
is
ipv6
only
that's
been
a
big
project
at
first
and
she
talked
about
it.
So,
yes,
we
have
some
islands
of
ipv6
only
capability.
E
A
J
E
J
Okay,
great
so
good
evening,
everybody,
my
name,
is
alexander
azimov.
I
work
for
yandex
and
today
I'm
going
to
discuss
with
you
flow
label
as
it's
on
this.
As
you
can
see
it's
on
the
slide,
it's
a
relation
to
the
tcp
circuit
hash
and
what
is
in
the
itf
documents
and
what
is
really
in
the
linux.
You
know
so
next
slide.
Please.
J
So
if
you
ask
data
tracker
about
flow
label,
it
will
give
you
this
kind
of
response,
so
these
all
rfcs
that
have
flow
label
in
its
naming.
Not
all
of
these
rfcs
are
related
to
flow
label
generation,
but
some
of
them
do
are
related,
some
of
them
even
look
obsolete
and
I'm
going
to
make
a
quick
recap
about
key
statements
in
these
rfcs
next
slide.
Please.
J
J
J
J
This
document
further
discusses
the
use
of
flow
label
as
packet
classification.
This
kind
of
use
case
brings
a
lot
of
complications
and
technical
requirements.
It
requires
to
keep
flow
label
stage
at
the
routers.
It
requires
special
processing
of
unknown
flow
labels.
Of
course,
this
requires
a
garbage,
collector
and
also
from
this
document.
It
starts
it's
of
course
required
that
flow
label
must
be
fixed
for
the
transport
connection.
J
So
it's
a
slightly
different
in
statements
from
the
previous
one
and
what
is
important
that
this
document
is
10
years
old
and
I
believe
that,
with
high
confidence
we
can
say
that
there
is
no
this
kind
of
deployment,
so
nobody
in
a
real
network
is
using
flow
label
as
for
package
classification,
at
least
I'm
not
aware
of
it.
Maybe
I'm
wrong
next
slide.
J
Tries
to
put
the
final
dot
to
the
argument
about
if
it's
good
to
use
a
stateful
or
stateless
flow
label,
and
so
it's
clearly
states
that
flow
label
should
be
used
in
status
allowed
distribution,
and
it
highlights
that
you
cannot
rely
for
at
flow
label
as
end
to
end
signal
because
it
may
be
change
in
the
path.
So
stateful
uses
of
flow
label
are
not
recommended
at
least
and
next
slide.
Please.
J
J
J
J
J
J
J
I
J
J
The
next
year,
this
solution
is
further
strengthened
and
now
the
hash
is
recalculated
upon
each
scene,
audio
or
any
kind
of
or
just
standard
rto
timeouts.
So
if
we
are
losing
scene
packet,
the
hash
value
is
changed.
If
we
have
rto
timeout
during
lifetime
of
tcp
session,
hash
is
changed
and
so
respectively
flow
label
is
changed.
J
J
So
in
this
case,
let's
say
that
there
is
an
outage
on
the
device
as
one
and
then
the
scene
packet
that
was
sent
from
t1
to
d2
was
lost
in
this
case.
According
to
the
linux
kernel,
the
hash
will
be
changed
and
so
flow
label
will
be
changed
and
to
redirect
the
second
scene
that
will
be
sent
from
the
one
host
to
another
to
another
path.
One
need
only
only
one
thing:
we
need
to
enable
flow
label
hashing
on
the
in
in-dress
device.
In
this
case
it
says
t1.
J
J
We
took
a
top-of-rack
switch
which
had
four
uplinks
and
on
one
of
their
uplinks,
we
created
a
packet
loss,
so
it
was
just
dropping
all
the
traffic
that
was
going
through
this
link
and
you
can
see
on
the
left
side
the
the
data
from
our
data
plane,
monitoring,
and
it
just
says
that
we
are
losing
twenty
five
percent
of
packets
that
are
distance
to
these
top
of
rex
switch
on
the
right
side.
You
can
see
the
disruption
that
happens
to
services
inside
this
switch
and
just
to
mention
it
says,
network
ipv6.
J
Please
now
we
enabled
a
flow
label
hashing
on
this
top
of
rack
switch
and
reproduced
our
experiment
on
the
left
side.
You
can
see
that
the
data
plane
monitoring
is
just
the
same
because
it's
not
aware
of
tcp,
it
just
sends
packets,
and
so
it's
still
sees
25
percent
of
packet
loss,
but
on
the
right
side
there
is
no
effect,
so
the
services
in
inside
this
wreck
were
not
aware
that
something
bad
happened
to
the
network.
J
J
And
as
we
discussed,
it's
not
only
flow
label,
it's
a
tcp
hash,
the
changes
and
there
are
dependencies
for
for
this
tcp
hash
in
a
linux
kernel.
So
it's
flow
label.
It's
and
every
other
kind
of
encapsulation,
for
example
upon
rto
it's
the
key
fields
in
gerry
will
be
changed.
It
will
change
also
source
port
in
the
edp
encapsulation.
And
if,
for
example,
you
will
use
any
kind
of
ipv6
encapsulation,
it
will
also
affect
the
flow
label
of
the
outer
header.
J
And
by
the
way
it's
a
linux
default,
so
the
default
behavior
is
to
use
this
kind
of
flow
label
generation.
So
at
the
moment
we
have
some
linux
kernel
developers
that
enriched
tcp
of
ipv6.
It
works
only
on
on
top
of
ipv6.
It's
not
working
for
ipv4,
of
course
enriched
it
with
self-healing
capability,
but
if
it
was
all
that
great,
I
would
not
have
created
these
slides
and
you
won't
be
suffering
from
my
russian
accent
next
slide.
Please.
J
J
For
example,
if
we
have
a
tcp
proxy
and
the
user
changes
a
flow
label
from
each
side,
it
may
result
that
the
following
packets
will
be
delivered
to
another
device
that
will
not
have
tcp
state
and
it
will
respond
with
a
rst
or
you
will
not
respond
at
all.
So
the
results
of
this
kind
of
situation
will
be
as
normally
session
timeout.
J
J
Normally
we
have
two
sides
of
tcp
session.
We
have
client
that's
unseen.
We
have
several
that
are
responsible
with
synagogue,
and
this
kind
of
problem
can
occur
only
on
the
side
of
the
client,
and
so
we
can
keep
the
behavior
of
the
server
as
it
is.
It
is
now
in
the
linux
kernel,
so
the
server
can
recalculate
its
tcp
hash
and
thus
change
flow
label
after
each
rto,
but
on
the
client
side
each
should
be
switched
by
default.
J
And
as
you
see
it's
just
in
my
last
last
slide
and
I'll
try
to
summarize
both
current
stagnation
and
deployment
status,
there
are
multiple
rfcs
related
to
flow
label
generation,
though
some
of
them
look
obsolete.
There
is
a
non-started
behavior
in
the
linux
kernel
and
maybe
other
operation
systems,
I'm
not
aware
about
it.
J
That
improves
tcp
connection
stability
in
case
of
packet
loss
on
one
of
the
parts
as
for
now
it
is
deployed,
at
least
at
three
hyperscale
clouds.
Unfortunately,
it
also
introduced
a
mistake
that
may
result
in
a
tcp
session
timeout.
It
can
be
fixed
and
a
good
thing.
According
to
the
discussion
in
the
mailing
list,
it
will
be
fixed,
but
I
believe
it's
also
important
to
update
related
standards
to
reflect
what
is
happening
in
the
real
world
deployments.
D
Yeah,
I
said
this
was
a
really
really
good
overview
of
flow
labels.
You
know
I
wanted
to
mention.
I
think
this
is
a
I
mean
you
know
comparing
like
ipv4
to
ipv6.
I
think
that
first
bullet,
that
you
I
mean
second
bullet,
you
know
flow
leg-
will
actively
use
for
state
stateless
load.
Balancing
I
mean
I
think
overall,
that's
that's,
really
a
real
massive
gain
like
going
from
b4
to
b6
so
with
with
v4,
because
there
is
no
like
there's
no
entropy
built
into
the
v4
packet,
no
flow
label.
D
You
can't
do
per
per
flow
low,
balancing
it's
versus
flow
based
load,
balancing,
so
every
flow
you
know
each
flow
is
hashed
to
an
individual
length.
Let's
say
if
you
have
an
ecmp,
so
so
the
the
really
the
huge
gain
with
really-
and
it's
really
overall
for
ipv6
deployments
for
operators
that,
if
you,
if
you,
if
you,
if
you
move
towards
ipv6,
being
able
to
take
advantage
of
that
stateful
load,
that
stateless
load
balancing
is
a
real
massive
gain.
You
know
with
that.
D
You
know
in
your
testing
that
you've
done
have
you
tested
across
different,
like
vendor
boxes
like
our
cisco
jana
per
arista
and
whatnot,
that
they
all
support,
stainless
load,
balancing,
because
that
that
uniform
load
balancing
that
you
can
get
with
that
with
the
flow
label.
It
is
a
massive
gain
for
operators.
J
So,
thank
you
very
much
for
this
very
positive
comment.
Yes,
we
tested
label
balancing
on
different
devices.
There
were
devices
that
were
not
working
properly,
some
of
them.
Some
of
the
vendors,
have
already
delivered
us
software
updates
and
we
are
waiting
for
the
last
of
threads.
If
there
are
updates
from,
I
cannot
name
the
vendor
in
this
q2.
K
Yeah,
so
you
said
you,
you
prefer
to
disable
this
feature
per
default
on
the
client
side,
because
you
may
reach
a
gcp
proxy,
a
different
tcp
proxy.
So
my
question
is:
if
you
change
the
flow
label
of
a
tcp
connection
on
the
server
side
in
the
middle
of
a
connection,
how
can
you
ensure
that
you
are
not
reaching
a
different
middle
box
like
a
firewall
which
sees
the
packets
and
has
no
states
from
before.
J
J
You
are
heavily
relying
that
all
packets
of
the
tcp
connection
today
are
coming
from
one
path.
Your
firewall
normally
will
not
be
working
that
good,
as
is
this,
is
possible.
So
if
you
have
a
symmetric
path
and
you
place
a
5v,
for
example
near
your
gateway,
single
gateway,
everything
will
be
perfectly
fine,
but
so
from
the
server
server
side,
it's
at
least
safe
from
the
client
side.
It
may
result
in
a
timeout.
If
you
are
uploading
a
lot
of
data
for
through
such
stateful
anycast
servers,
it
may
be
some
proxy.
K
I'm
not
talking
about
any
cost,
I'm
talking
about
a
unicast
service.
Fireworks
are
on
a
path
and
now
one
side
changes
the
flow
label
resulting
in
packets,
taking
a
different
way
through
the
network.
So
it
might
not
hit
the
firewall
anymore,
so
a
new
firewall
might
be
hit
and
the
connection
will
die.
J
K
J
I'm
talking
about
another
source
of
changing
path
from
content
provider,
for
example,
and
the
end
user.
So
if
you
have
multiple
firewalls
that
are
expected
to
be
processing
the
tcp
session
with
without
traffic
redirection,
I
think
it's
already
broken
without
any
flow
label
changing
and
by
the
way
label
is
already
changing.
So
it's
not
something
that
I
suggest
to
introduce.
It's
what's
happening
now,.
A
L
I
wonder
with
your
proposal
of
on
safe
mode,
what
happens
if
the
the
path
is
asymmetric
and
the
problem
is,
in
the
let's
say
the
uplink
from
the
client
to
the
server,
and
in
that
case
you
you,
you
don't
have
the
simple
performance
you
showed
with
this
experiment
where
you
had
the
75
percent.
Stop
right.
J
There
is
a
trade-off,
so
just
be
a
timeout
in
some
kind
in
some
situations
or
benefits
in
another,
the
safe
mode.
As
I
say,
it
is
a
an
easy
fix,
after
that,
one
can
think
about
for
a
kind
of
negotiation,
negotiation
between
client
and
server
that
in
which
the
server
will
permit
client
to
change
its
flow
label,
for
example,
if
the
server
knows
that
everything
will
be
fine,
okay,
just
do
it,
but
safe
mode
is
from
my
standpoint
is
something
that
should
be
deployed
in
first
place.
L
M
D
All
right
thanks,
I
added
just
another
quick
question.
You
know,
because
you've
had
seemed
like
a
lot
of
erratic
results
with
using
state.
You
know
the
stateful
marking
of
the
flow
label
is.
Is
there
a
feature?
I
guess
you
know
probably
from
an
operator's
standpoint.
Maybe
it
makes
sense
to
like
you
know,
like
let's
say
with
qos,
you
can
actually
have
trust
to
like
trust.
D
The
flow
is
there
a
way
to
like
remark:
the
packets
on
a
on
a
switch,
so
the
flow
may
sort
of
so
you
unmarked
the
packets,
and
so
the
flow
label
is
not
set.
You
know,
let's
say
on
the
a
port
connected
to
a
host
that
you
can.
You
know,
keep
it
untrusted
or
just
mark
it
so
that
it
does
it's
not
used.
So
that's
so
that
hosts
don't
actually
try
to
use
stateful
because
of
the
erratic
behavior
that
you
can
see
with
stateful.
J
Thank
you
I'll
try
to
answer
this
question,
though
I
can't
say
that
I've
followed
it
fully,
but
so
we
never
remark
flow
label
at
the
top
of
rack
switches
or
in
any
part
of
the
network.
No
part
of
the
network
keeps
keeps
the
state
of
the
flow
level
it's
just
in
the
hash
function
of
ingress
devices
and
the
ingress
device
may
be
top
of
rack
switch.
It
may
be
right
at
the
entrance
of
a
mpls
cloud
right.
J
D
I
understood,
but
you
know
on
this
on
this
on
the
top
of
rack.
Like
that
ingress
point,
could
you
actually
just
like
a
qos
packet
like
the
dsc
toss
field?
Can
you
you
know
set
it
to
everything
is
so
that
the
the
field
is
not
marked,
so
you
don't
have
erratic
behavior
because
it
does
seem
like
when
the
host
sets.
You
know
and
tries
to
use
a
flow
label
for
stateful
operation
that
it
seems
like
from
your
testing.
D
J
A
A
A
N
N
N
So
when
analyzing
the
address
properties,
we
came
up
with
a
you
know
with
a
few
different
categories.
The
first
one
is
that
of
scope,
which
is
actually
you
know
formally
defined
in
the
ipv6
addressing
architecture.
Essentially,
the
scope
is
the
network
span
where
another
is
uniquely
identifies
a
network
interface.
Okay,
as
a
consequence
of
of
that,
you
can
say
that
you
know
the
scope
has
an
implication
on
reachability.
Reachability
will
always
be
smaller
than
the
scope
of
the
address,
and
there
are
implications
of
the
of
the
scope.
N
N
It
also
has
implications
of
on
address
stability,
for
example,
for
the
particular
case
of
you
know
global
addresses,
if
you
have
provider
dependent
addresses,
then
you
know
your
addresses
might
change
over
time.
For
example,
if
your
app
stream
were
numbers
second
property
that
we
discuss
in
the
document
is
that
of
reachability,
which
essentially
implies
more
than
just
the
scope,
because
it
also
implies.
N
I
mean
the
scope
does
imply
a
limit
on
reachability,
but
there
are
other
things
that
affect
reachability
such
as,
for
example,
filtering
policies,
and
the
implications
of
reachability
is,
of
course,
of
course
that,
of
course,
exposure.
Okay,
you
know
another
is
that
is
you
know,
reachable
from
everywhere
of
course
means
that
that
know
that
host
is
also
reachable.
You
know,
from
everywhere,
for
example,
for
attack
purposes.
N
N
Slide
other
categories
provider
dependency.
This
is
you
know,
provider
dependency
is
normally
analyzed
in
the
context
of
you
know.
Global
addresses,
like
you
know,
bi
versus
pa
space,
but
in
this
case
you
know
we
we
talk
about
this
property
like
in
a
more
general
way,
and
essentially
we
refer
to
this
property.
As
you
know,
the
extent
to
which
an
address
is
tied
to
your
upstream
provider
upstream
provider
could
be
anything
could
be
another
router
in
your
same
network
and
that
router
might
be
leasing.
You
ula
prefixes,
okay.
N
So
the
idea
here
is,
you
know
if
the
address
that
you're
using
depends
on
the
upstream,
then
it's
you
know
dependent
on
the
provider
and
if
not,
it's
not
implications
of
this.
One
of
them
is
other
stability
like,
for
example,
the
work
that
we
have
done
in
basic
subs
about
the
flash,
remembering
events.
So
if
your
address
depends
on
your
provider,
then
if
they
provide
the
real
numbers,
then
you
know
your
addresses,
will
change
and,
for
example,
in
the
case
of
global
addresses,
like
pei
vs
pa
space.
N
Obviously,
it
has
an
implication
on
your
ability
to
do
multi-homing,
okay,
the
final
one,
if
I
remember
correctly,
is
that
of
stability
which,
as
the
name
implies,
has
to
do
with
the
extent
to
which
an
address
changes
over
time.
You
know
the
other
exchanges
are
associated
with
at
least
two
different
things.
One
is
the
prefix
stability.
N
N
It
also
has
implications
on
privacy
because
of
course,
the
more
you
use
an
address.
You
know
the
longer
you
will
allow
for
network
activity
correlation
based
on
the
address
itself.
Of
course,
there
are
many
ways
in
which
you
can
correlate
activity
and
finally,
it
also
has
implications
on
operations.
Why?
Because,
for
example,
there
are
devices
that
might
not
be
able
to
cope
with.
You
know,
systems
employing
many
addresses
or
with
changing,
addresses
all
the
time
all
the
times
in
some
enterprise
deployments,
they
might
expect
the
addresses
to
be
stable.
N
You
know
for
correlation
or
login
purposes,
for
acls
too.
There
were
also
comments
on
the
on
the
v6
ops,
mainly
list
regarding
acls
that
you
might
even
want
to
you
know,
enforce
on
your
cpu
router.
You
know,
since
you
know,
if
your
home
network
is
employing
global
address
space,
it
might
be
difficult
for
you
to
configure
acls
on
your
cpe,
because
if
your
you
know,
if
your
isp
renumbers
you,
then
you
know
the
acls
should
change
accordingly.
So
there
are
a
number
of
implications
associated
with
stability.
N
N
Slide:
okay,
so
how
are
addresses
currently
being
employed?
Well,
when
it
comes
to
configuration
it's
normally
one
size
fits
all
like,
for
example,
I
use
uhuntu
on
my
laptop
and
I
get
the
same
kind
of
addresses,
no
matter
where
I
connect
to,
for
example,
ubuntu
will,
if
addresses
are
being
provided
with
slack
and
the
hcp
it
will
configure
addresses
with
both
and
when
it
comes
to
slack,
it
will
configure
both
stable
and
temporary
addresses
and
it
doesn't
matter
what
kind
of
network
I
connect
to.
N
I
always
get
the
ubuntu
has
the
at
least.
As
far
as
I
know,
the
you
know
the
same
policy
for
you
know,
configuring
addresses
where
you
might
want
to
do
something
different.
Okay,
for
example,
if
you
were
to
you,
know,
connect
to
your
home
network,
you
might
want
to
do
both
stable
and
temporary
addresses,
but
if,
for
example,
you
have
a
you
know,
a
mobile
device,
you
might
want
to
use
just
temporary
addresses.
N
Okay
when
it
comes
to
usage,
it's
the
same
thing,
so
the
approach
that
is
normally
employed
is
one
size
fits
all.
So
when
it
comes
to
clients,
normally,
you
know
hosts
employ
the
you
know:
ipv6
defaults,
the
default
address
selection.
You
know,
meaning
that
you
know
you
pick
your
source
and
destination
addresses
based
on
that
rfc
and
when
it
comes
to
you
know,
servers
or
server
like
operations.
N
You
know
the
normal
behavior
is
that
you
accept
incoming
connections
on
all
of
the
configured
addresses.
Okay,
which
is
you
know
at
the
very
you
know
at
least
sub
optimal,
because
that
means
that,
for
example,
addresses
that
you
expose
to
the
outside
world
by
doing
client-like,
communications
could
also
be
leverage
are
used
to
actually
access
services
that
you
might
be
providing
in
your
local
node.
There
are.
N
There
is
like
a
famous
case
of
you
know,
of
host
systems
that
they
were
exposing
their
ipv6
addresses
when
using
ntp
to
synchronize
the
time,
and
then
you
know,
right
after
you
know
doing
ntp,
they
got
poor
scan
by
using
the
you
know.
The
temporary
address
that
had
been
employed
with
mtp
next
slide.
N
N
You
know,
configure
many
addresses,
which
is
actually
a
bcp
right
now,
but
you
know
the
network
might
not
be
willing
to
do
that,
or
maybe
the
network
might
be
willing
to
allow
for
some
number
of
addresses
you
know
per
cause,
but
it's
impossible
for
the
host
to
know
what
that
number
is.
What
what's
like
a
you
know,
a
number
of
addresses
that
is
acceptable
to
the
network,
so
you
have
a
case
of
you
know
different
expectations
from
the
host
side
and
from
the
network
side.
N
There
is
also
the
issue
of
slack
and
dhcp
interaction.
For
example.
That's
the
case
of
my
own
box.
I
have
an
ubuntu
box
that
does
7217
and
4941
for
configuring.
The
slack
addresses
that
is
it
configures
slack
addresses
in
a
way
that
you
know
you
take
care
of
security
and
privacy,
but
ubuntu
by
default.
If
addresses
are
also
offered
on
dhcp,
it
will
configure
addresses
with
the
acp
too,
and
I
happen
to
have
you
know
a
cpe
router
that
leases
ipv6
addresses
using
a
predictable
algorithm.
N
So
my
slack
addresses
are
unpredictable.
My
my
dhcp
addresses
are,
you
know,
pretty
predictable
and,
of
course,
of
course,
the
you
know,
the
the
you
know
the
outcome
of
that
is,
you
know
at
best
sub
optimal.
When
it
comes
to
address
usage.
There
are
also
implications,
for
example,
an
application
that
expects
to
have
a
long
live
session,
might
use
temporary
addresses,
which
you
know
as
a
result
of
that
results
in
the
sessions
being
torn
down.
N
Think,
for
example,
about
the
case
where
you
want
to
have
a
you
know:
long
live
ssh
session,
but
ssh
employs
temporary
addresses
and,
as
a
result
of
that,
you
know
they
get
the
the
session
gets,
you
know
closed
or
down
every
time
you
could
also
end
up
using,
for
example,
global
addresses
for
what's
meant
to
be
a
service
that
is
only
provided
on.
The
local
link
could
be
the
case,
for
example,
for
multicast
dns.
N
If
you
wish,
and
there's
also
the
case
that
it's
what
happens
nowadays,
that
you
may
be
accepting,
you
know
incoming
connections
on
all
addresses,
including
temporary
addresses,
meaning
that,
just
by
you
know,
exposing
your
temporary
addresses
means
that
you're
also
or
you
might
also
be
exposing
services.
That
might
even
be
meant
only
for
you
know
the
local
network
next
slide.
N
So,
let's
go
briefly
through
some
of
the
gaps
that
we
have.
One
is
the
apis.
Essentially,
you
know.
For
the
most
part,
we
keep
using
the
same
kind
of
apis
that
you
know
do
not
really
you
know,
allow
applications.
You
know
to
essentially
signal
what
kind
of
properties
they
expect
on
the
underlying
ipv6
addresses.
So,
for
example,
for
a
client
application.
N
N
There's
probably
also
room
for
advice
on
ipv6
address
usage,
meaning
that
even
if
we
have
those
apis,
then
you
know
we
should
provide
advice
to
you
know
applications
developers,
you
know
for
them.
You
know
to
to
to
be
aware
about
both
the
api
and
what
supposed
to
be
the
you
know.
The
best
way
of
you
know
leveraging
ipv6
services
next.
N
N
This
is
kind
of
like
you
know.
The
result
of
conversations
that
we
have
had
in
six
months,
for
example,
allow
the
network
to
convey
information
about.
You
know
their
expectations
of
addresses
so
that
you
know
the
costs
and
the
you
know
network
can
cooperate
in
a
better
way,
whereas
nowadays
the
host
may
configure
many
addresses,
but
it
might
hit
a
point
where
you
know
the
network
isn't
happy
about
that.
There
have
been
proposals.
This
is
obviously
work.
N
Finally,
there's
other
stuff,
one
is
support
for
firewall
traversal
in
cpus.
Essentially,
you
know
when
you
look
that
you
have
many
cps
that
enforce
a
policy
of
only
allowing
outgoing
communications.
That's
kind
of
like
mimicking
what
we
have
in
ipv4
as
a
side
effect,
but
they
don't
have
support
for
things
like,
let's
say:
ipv6
based
universal
plug
and
play
or
pcp.
N
That
means
that
in
many
cases
you
might
end
up
having
ipv6
network
where
your
local
nodes
employ
global
addresses,
but
that
filtering
policy
of
only
allowing
outgoing
connections
essentially
prevents
you
from
offering
services
with
dhcp,
which
is
kind
of
like
ironic
and
last
item,
is
support
for
multi-prefix
multi-router
networks.
To
put
it
bluntly,
we
do
from
my
perspective,
we
do
need
mandatory
support
for
rfc
8028.
N
For
me,
it's
virtually
impossible
for
a
network
to
support
a
setup
where
you
have.
You
know
multiple
routers
and
multiple
prefixes.
The
requirement
for
at
rfc
8028
right
now
is
assured,
but
from
my
perspective,
it's
like
should
be
a
must,
like
you
know.
Definitely
a
must,
and
we
also
need,
of
course,
increased
support
of
it,
because
the
vast
majority
of
ipv6
implementations
do
not
really
support
ad28
next
slide.
F
Hi,
fernando
thanks
very
interesting
documents.
However,
I
have
a
few
comments.
First
of
all,
I'm
surprised
with
the
saying
that
your
your
laptop
is
always
configured
the
same
way.
I
might
be
wrong,
but
I
think
network
manager
does
allow
you
to
have
different
profiles
for
different
process
ids.
You
can
have
only
stable
address
in
one
advisory
networks
and
private
extensions
on
another
and
so
on.
F
I
think
the
functionality
is
actually
already
here
so,
and
I
think
the
document
actually
covers
a
lot
of
different
things,
because
I
agree
with
definitely
leading
api,
so
application
could
get
better
visibility
to
property
of
address
temporary
versus
stable
and
so
on.
However,
concerns
that
some
other
properties
are
not
really
property
of
an
address.
F
It's
a
property
of
the
network
topology
at
this
particular
moment
of
time
right,
for
example,
the
particular
network
block
reuse,
now
might
be
provided
by
isp,
but
as
a
result
of
some
paper
work
done,
it
might
become
a
property
of
the
network.
So
it's
not
pay
anymore.
So
I'm
not
sure
about
your
suggestion.
Theory.
How
can
we
get
that
as
those
properties
communicated
in
programmatical
way.
N
Well,
one
of
the
options,
but
that's
just
scratching
the
surface,
and,
to
be
honest,
I
don't
know
the
extent
to
which
that
is,
you
know,
implemented
at
the
time
temporary
addresses
you
know
were
specified.
There
was
there's
actually
an
rfc.
I
don't
remember
the
status
of
that
rfc,
but
to
have,
for
example,
a
socket
option
that
allows
an
application
to
select
if
you
want
temporary
addresses
so
one
of
the
possible
ways
in
which
that
could
be
exposed.
N
N
I
said
as
a
comment.
Sorry
I
remember
I
once
like
maybe
a
couple
of
years
ago.
I
discussed
this
a
little
bit
in
you
know
in
tabs
and
essentially,
and
it
made
sense
like
the
false
attacks
said
you
know,
we'd
like
to
do
something
you
know
on
the
topic.
That's
what
I
remember
at
least,
but
they
say.
Well,
we
don't
necessarily
you
know,
have
the
the
skill
set
and
the
knowledge
about
you
know
the
ipv6
specifics.
N
N
So,
from
my
perspective,
I
would
think
that
well,
first
of
all
agree
on
the
problem,
and
I
would
say
that
you
know
once
we
we
agree
on
the
problem.
You
know
one
possibility
is
to
have
a
separate
document
in
you
know:
basic
shops
that
talks
about
the
the
properties
that
you
know,
that
about
the
ipv6
address
properties,
and
you
know
how
we
think
they
should
be
exposed
to,
for
example,
applications
or
you
know,
no
matter
where
the
home
is
whether
that's
visible,
b6,
b6,
ops
or
taps.
N
Essentially,
if
we
agree
on
the
problem
we
could
discuss
with
the
tops
people
you
know
of
what
what
is
the
best
way
in
which
they
could
eventually,
you
know,
act
on
that,
whether
they
need
something
on
basic
shops.
You
know
from
where
they
could
take,
and
you
know,
do
the
protocol
related
development
that
might
be
needed,
for
example,
all
the
discussion
about
the
the
other
properties.
What
properties
might
make
sense
to
be
exposed
to
the
application,
and
so
on
that
should
certainly
come
from.
You
know.
N
A
I
guess
I
don't
want
to
import
caps
into
v6
ops,
you
know
caps
plugs
and
taps,
so
we
need
to
figure
out
the
best
way
we
can
help
them
do
what
we
want
them
to
do.
Something
that
might
be
important
to
them,
though,
could
be
a
set
of
requirements.
Yes,
I
was
trying
to
figure
out
that
interface.
I
would
want
something
from
the
application
that
says
gee.
I
really
wish.
N
Yeah
one
thing
that
you
know
the
one
one
one
problem
with
that
is
that
the
people
that
might
benefit
from
that
they
don't
necessarily
you
know,
have
the
detailed
knowledge
about
the
properties
that
we
have.
So
is
that
the
guys
that
would
use
it?
Maybe
they
are,
you,
know
noah.
They
are
not
really
aware
about
the
details.
That's
why
I
think
they're.
You
know
some
sort
of
coordination
between
you
know
the
the
b6
people
and
the
application
people
might
be
necessary
here
right.
N
I
don't
know
you
know
the
exact
way
of
of
doing
that
and
you
know
for
sure.
I
think
that
you
know
this
document
is
a
problem
statement,
but
for
each
of
the
things
and
each
of
the
gaps
that
are
you
know
discussed
there
should
certainly
be
you
know
at
the
very
least,
some
spin-off
document
that
you
know
focuses.
You
know
on
that
on
on
coming
up
with
a
you
know,
a
more
detailed
problem
statement
or
a
solution.
A
Well,
that
may
be,
you
know
once
again.
That
would
be
something
that
I
would
think
that
that
ron
and
I
could
talk,
including
you
with
caps
chairs
and
try
to
figure
out
where,
where
those
requirements
would
come
from
now,
I
don't
want
to
we're
actually
five
minutes
overtime
and
we've
still
got
luigi
and
bob
in
the
queue.
So
let
me
turn
this
to
them
luigi.
What
did
you
have
to
say.
L
L
C
Yeah
I'll
be
quick
yeah.
I
think
there
may
be
some
things
in
here
that
are
worth
pursuing,
but
I'm
not
comfortable
with
the
sort
of
large
document
that
covers
a
whole
bunch
of
stuff
and,
as
jen
said,
it
seems
to
be
a
little
confused
about
like
what
the
properties
of
an
address
is,
because,
just
because
you
get
renumbered,
the
address
is
still
quite
stable.
You
just
don't
get
to
use
it
anymore,
so
I
think
you
know
I
I
think
pull
using
this
pulling
this
out.