►
From YouTube: IETF109-V6OPS-20201119-0900
Description
V6OPS meeting session at IETF109
2020/11/19 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
C
Hey
ron
and
fred
sorry
to
interrupt
just
wanted
you
all
to
know
that
chat
is
down
right
now.
Jabra.Itf.Org
is
experiencing
an
outage,
so
chat's
not
going
to
work
until
that
gets
fixed
and
it's
being
investigated.
A
C
D
A
A
A
A
H
I
guess
yeah
somehow
I
have
a
difficulty
in
starting
video.
Oh.
H
Yeah
so
hi
everyone.
This
is
ramesh
chandra
from
relianzio.
H
Many
of
you
are
not
familiar
about
reliant
jio
quickly.
In
couple
of
seconds,
we
started
a
commercial
network,
early
2016.
and
almost
we
have
completed
four
years
in
four
years.
Today
we
are
carrying
highest
number
of
mobile
subscriber
on
ipv6
globally.
That
is
the
stage
what
we
have
done.
So
in
this
four
years
we
are
going
to
share
in
couple
of
slides
what
was
our
journey?
What
we
did,
what
is
the
strategy
which
followed?
H
H
Yeah
so
in
this
discussion
I
guess
we
have
a
15
20
minutes
time
to
cover
up
this
and
back
more
10,
12
slides,
so
we're
going
to
talk
about
strategy.
What
is
the
present
status
of
the
ipv6
deployment
and
the
challenges
we
just
briefly
talk
about
and
what
are
the
solutions
which
we
think
are
possible?
H
Need
now
briefly,
if
we
talk
about
2015,
when
we
started
building
a
new
organization
for
providing
40
services,
we
had
a
options
like
now.
What
do
we
start
with?
Should
we
start
with
ipv6?
We
start
with
the
dual
stack
and
we
start
with
the
traditional,
the
way
ipv4
being
deployed,
and
then
we
had
couple
of
thoughts
in
plasma
like
this
market,
where
even
not
only
a
network
telecom
network
infrastructure.
H
When
we
have
to
look
at
the
complete
ecosystem
device
market
applications
network
infrastructures,
all
these
components
put
together
need
to
decide
what
is
the
right
strategy?
We
need
to
follow
to
start
with,
and
of
course
this
is
the
open
market.
India
is
a
completely
open
market
where
subscriber
decide
what
devices
he
is
going
to
use.
H
Okay
and
then
the
device
has
to
work
in
operator,
environment,
so
environment,
a
little
more
challenging
than
even
other
geographies,
which
we
see
when
the
some
of
the
services
were
due
home
device
is
also
provided
by
operator
that
is
well
comparatively
religious,
highly
price
sensitive,
because
even
the
income,
great
group
of
the
people
highly
impactful,
slightly
comparatively
lower.
So
people
are
very
sensitive
to
any
extra
price,
with
the
pay
even
to
the
operator
and
then
ipv6
in
2015.
H
It
was
very
at
early
stage
and
even
application
provider
whether
it
was
a
oem
community,
even
the
devices
side,
it
was
not
very
mature,
so
it
was
very
early
stage.
Similarly,
when
we
were
working
for
applications
when
the
cdn
providers
they're
also
building
the
dual
style
network,
so
what
we
started
at
this
is
maybe
it
is
not
right
to
push
ipv6
okay
to
begin
with,
so
we
adopted.
Okay,
dual
stack
is
the
option
to
start
with.
While
we
start
dual
stack,
ipv6
only
is
the
right
direction
forward.
So
what
we
did?
H
We
set
the
directions
inside
the
organization
any
product
and
technology
we
select.
We
have
to
be
ipv6
ready
and
no
matter
how
great
the
product,
if
it
is
not
supporting
ipv6.
Definitely
that
is
not
right.
The
platform
right
technology
for
us
to
choose,
so
that
is
the
strategic
direction
which
is
with
the
organization
while
desiring
any
product,
and
that
is
the
reason
even
after
starting
implementation.
Even
today
we
see
whole
of
the
network.
We
see
even
ipv6
ready,
let's
go
to
next
slide.
Please.
H
Yeah,
I
can,
I
can
do
that
so
in
this
four
years
of
journey,
what
we
see
is,
like
you
know,
for
a
voice
over
lte
by
vvm
services
depends
on
the
device
type
so,
based
on
that
tracking
area
code,
we
assign
ipv6.
So
all
the
devices
we
support
impact
voice
over
lte
when
signaling
data
plane
services
we
assign
ipv6
only
so
what
we
see
in
the
network.
Today,
almost
90
percent
of
the
devices.
Okay,
we
assign
only
ipv6
okay
for
the
voice
levels.
Lte
services.
H
There
are
still
like
10
percent
devices,
where
there
are
certain
devices
challenges
which
will
talk
about
subsequent
slides.
So
ninety
percent
is
working
only
on
ipv6
line
on
the
network
infrastructure.
H
If
you
look
at
like
you
know
whether
the
erode
v,
the
small
cell,
loud
or
small
cell
indoor,
small
cell
access
point,
okay
utilities,
all
various
complete
network
infrastructure,
it
is
all
ipv6
when
we
talk
about
management's
platforms
when
the
devices
router
switches,
nms,
cms,
okay,
all
of
them
on
ipv6,
and
similarly,
when
some
of
the
security
systems
which
you
have
built
up
and
then
to
manage
securities.
Okay,
some
of
the
smps
control
systems,
but
also
they're
managing
ipv6.
H
D
F
I
Okay,
I
touched
mute
all
with
the
idea
that
that's
supposed
to
mute
everybody
except
you
and
I
and
the
speaker-
and
I
may
have
accidentally
muted
from
mesh.
If
so
for
a
mesh,
you
need
to
touch
the
the
mute
audio
button
or
the
unmute
audio
button.
F
E
I
I
Well,
fernando
writes
in
the
chat
that
he's
texting
him,
but
he's
not.
That
doesn't
seem
to
be
getting
through.
I
H
Yeah
yeah,
so
can
you
start
it
now.
H
Oh,
thank
you
so,
on
the
dual
stack
journey,
what
we
look
at
it
when
4g
lte,
as
well
as
the
fttx
high
speed
internet
services,
when
the
user
devices
and
many
of
the
user
devices
wherein
there
are
other
devices
at
the
teething
mode,
maybe
at
home,
where
we
connect,
maybe
laptop
or
desktop
okay
and
these
devices,
maybe
in
the
teeth
ring,
are
still
on
ipv4
because
of
maybe
various
other
reasons.
So
there
is
a
region
on
ipv6
for
the
high
speed
internet
for
the
mobile
devices.
H
We
it
was
found
very
challenging
in
parallel
to
us
and
only
ipv6,
because
the
moment
we
turn
on
only
ipv6,
then
we
have
to
use
even
the
c
lat
functionality
and
then,
when
we
turn
on
c
lat
functionality,
we
have
some
other
various
obvious
reasons.
Okay,
what
are
the
regions
and
what
is
the
solution?
H
We'll
talk
subsequently,
so
high-speed
internet
services,
that
is
in
the
dual
stack,
which
are
offering
both
for
the
mobile
as
well
as
the
fixed
line
species
many
of
the
applications
so
application
part
when
the
jio
has
not
only
built
up
the
cdn
operator
network
within
our
network.
These
are
more
popular
in
the
industry,
whether
it
is
a
google
or
kumai
or
is
limelight
and
many
many
many
others.
H
We
also
build
up
our
own
cdn
infrastructure,
where
we
have
our
own
application
content.
So
jio
is
no
more
only
a
impact.
My
connection
provider
will
build
up
complete
ecosystem,
our
own
content
and
all
those
content.
What
we
have
developed
on
an
ipv6
so,
of
course,
to
support
even
other
subscribers
who
are
coming
ipv6.
We
have
to
support
them.
That
is
where
it
is
on
the
dual
stack.
H
While
network
infrastructure,
it
is
easier
because
we
have
to
support
ipv4.
That
is
where
the
mat
we
need
to
integrally
build
up,
which
we
can't
avoid
it.
But
when
you
move
to
the
enterprise
infrastructure
and
in
in
the
office
like
enterprise
offices,
where
we
have
a
landline
infrastructure
and
the
applications,
so
those
are
still
and
on
dual
stack
and
to
support
the
main
enterprise,
because
they
have
a
public
on
contents
and
those
needs
to
be
accessed
from
the
internet,
and
that
is
where
continuous
requirement
of
public
ipv4
keep
coming.
H
And
when
we
go
for
the
oss
bss.
Of
course,
it
has
to
be
on
the
dual
stack
to
support
it,
some
other
things
like
isis,
so
I
guess
those
are
no
more
the
challenges
and
it
is
working.
So
I
feel
whole
of
that,
in
fact,
although
major
part
of
the
network
and
ipv6
but
majority
of
the
infrastructure,
because
ip4
is
still
running
on
the
dual
stack.
H
If
you
look
at
the
jio
cloud
network
infrastructure,
what
we
have
built
up
and
we
are
providing
content
even
to
subscriber
even
to
the
even
other,
subscribers
not
connected
with
the
jio.
So
what
we
see
number
of
requests,
which
is
serve
on
ipv6,
are
more
than
94
and
remaining
we
talk
about
six
percent
or
five
percent
of
the
requests
which
are
served
on.
Ipv4S
are
majority
of
them,
maybe
more
than
50
percent
requests,
which
are
coming
from
other
operators
through
the
peering
or
throwing
back
private
pairing
of
public
pairing
which
we
have.
H
H
Now,
while
we
did
this
part
now,
there
are
couple
of
challenges
which
we
experience
and
these
challenges.
For
example,
if
we
talk
about
it,
eight
percent
of
almost
eight
percent
of
the
chipsets
used
in
the
mobile
devices
do
not
comply
with
the
sealant,
which
is
rfc
6807,
and
while
we
took
this
cases
with
the
oems
who
are
providing
mobile
devices,
okay
and
then
we
come
to
there
are
various
other
regions
and
they
also
have
some
business
region
and
they
say
the
devices
and
chipset
which
you
use.
H
We
are
in
process
of
phasing
that
out
and
we
have
in
your
devices
we
supported,
but
you
don't
have
a
compliance
with
existing
device
now,
fortunately,
unfortunately,
since
device
is
sold
to
the
subscriber
in
the
market,
as
long
as
the
device
is
working
subscriber
is
not
going
to
replace
because
it
is
not
working
ippc,
it
really.
H
So
that
is
the
reason
what
we
see
even
the
network:
okay,
almost
eight
percent
of
the
devices
since
they
fail
on
the
sealat
compliance
and
because
of
this
we
cannot
move
into
a
hundred
percent
devices
on
ipv6
only
stack,
and
we
have
also
seen
even
the
sim,
which
comes
which
we
insert
in
the
mobile
device
and
for
that
device
in
the
sim
to
manage
the
device
we
have
to
prevent
ip
address
for
the
managing
the
device
and
to
do
that.
Traditionally,
as
a
industry
started,
it
is
only.
F
H
Which
is
pre-configured
in
the
same
to
manage
the
device.
While
we
started
this
exercise,
we
have
make
sure
all
the
new
sims
which
we
have
multiple
suppliers.
We
buy
the
sim
where
we
burn
ipv4
and
v6
both
so
that
anytime,
you
need
to
manage
the
device
using
an
ipv6.
You
are
able
to
reach
to
the
device
so,
but
the
situation
is
like
now.
These
sims
are
in
the
market.
These
are
with
the
devices
and
if
we
assign
based
on
the
tag
tag
code,
we
assign
only
ipv6
and
the
sim
is
only
have
ipv4.
H
H
It
is
not
a
really
technology
elimination,
it's
more
of
a
operator
environment,
because
this
sims
needs
to
be
pre-configured,
ipv4,
v6
and
even
the
device
is
switched
off
by
subscriber
it's
keeping
at
home
and
when
we
decide
to
utilize
it
when
it's
turned
on,
then
only
we
are
going
to
push
the
configuration
from
the
network
to
update
the
profile
in
the
sim
so
that
it
is
ready
and
ipv4
v6.
And
when
he's
going
to
do
it,
okay,
how
soon
is
going
to
be.
That
is
always
the
challenge
which
we
face.
H
H
Thank
you
so
well.
This
is
one
side.
The
iot
is
another
area
where
the
highly
focused
lot
of
focus,
effort
and
the
commitments,
the
two
things
which
is
coming
very
clearly.
Yes,
this
is
the
area
where
we
need
to
focus
and
what
we
see
there
are
clearly
identified,
use
cases,
applications
which
are
ready
for
the
industry
to
really
come
up
now.
The
challenge,
what
we
see
is
that
many
of
like
dbr
nvr
cameras
which
are
available
in
the
market
today
we
did
certain
analysis
and
the
validation.
H
How
many
of
these
tv-
and
you
are
support,
ipv6
and
to
like
you,
know,
surprise
that
almost
like
90
percent
of
the
dvr
nvrs
are
only
supporting
ipv4
and
even
for
them
to
turn
and
ipv6
ready.
Nothing
can
be
done
because
I
cannot
be
changed
by
just
changing
the
firmware
of
the
software,
because
the
hardware
chipset,
which
is
used
possibly
do
not
have
a
dual
stack
support,
so
that
is
one
area
where
that
needs
to
be
really
focused
and
come
out
how
we
can
make
that
ipv6
ready.
H
Similarly,
even
the
sensors
like
whether
it
is
smart
metering
or
any
impact,
no
home
light
sensors,
any
other
sensor
have
to
be
ipv6
supporting.
Otherwise,
if
we
don't
have,
then
definitely
the
challenge
is
what
we
see
in
the
network
site
similar
challenging,
will
come
in
the
iit
also
and
even
to
enable
them
to
support
them.
There
could
be
options
where
the
support
only
literally
change
in
the
software
from
there
can
enable
ipv6
for
one
area.
Second,
is
that
in
case
of
the
hardware
impact
we
know
that
it
may
not
be
feasible.
H
If
we
look
at
this
enterprises
business,
what
we
look
at
it,
what
do
we
have
really
in
the
enterprises
like
no,
the
router,
the
firewall?
There
could
be
switches.
There
could
be
some
office
automation
machines,
there
could
be
a
left,
server,
email,
server,
database,
copier
machines,
branding
message.
Various
other
like
every
office
has
all
these
system
and
if
you
look
at
the
today's
operating
systems,
we
look
at
that.
Today's
most
of
these
platforms,
okay,
what
we
see
are
supporting
ipv6.
H
So
very
we
really
don't
see
that.
Okay,
there
is
a
real
challenge
in
migrating
enterprise
setup
to
ipvc.
There
are
very,
very
very
few
I
can
think
of.
I
can't
even
think
of
that.
Okay,
these
systems
are
not
supporting.
Maybe
some
upgrade
are
required.
New
software
legion
required,
but
definitely
we
do
have
a
support,
but
what
we
see
somehow
we
don't
see
this
enterprise
houses.
They
have
a
priority
to
impact,
bring
the
change
and
update
the
network
infrastructure
and
make
from
ipv4
to
12
stack.
H
They
don't
see,
there
is
a
reality.
They
don't
see
that
they
need,
they
don't
see.
Okay,
we
don't
see.
There
is
a
like.
You
know
a
drive
from
them,
okay
to
make
this
change
and
make
this
ipv6
ready,
and
in
any
case,
because
there
are
the
public
ipv
force
available,
so
they
don't
see
in
five
minute
to
migrate
to
so
that
is
how
enterprise
is
running.
Even
the
dual
stack
today,.
H
We
did
certain
analysis
on
like
no
top
10
website
of
six
different
categories
with
the
sources
mentioned
below
these
stops
top
10,
based
on
their
ranking
and
based
on
the
criteria.
We
looked
at
analysis.
How
many
of
these
websites
are
really
working
on
ipv6,
and
these
are
the
most
popular
top
10
website
of
six
different
categories
where,
like
you
know
some
of
these
commercials,
some
of
these
finance
games
sports.
H
Okay,
now
we
were
very
excited,
hopefully,
because
industry
is
moving
ipv6
when
these
websites,
these
websites
should
also
be
migrating,
at
least
to
dual
stack
ipv6
only
and
what
it
came
to
surprise,
which
is
in
the
next
slide
that
out
of
these
60
website.
If
you
look
at
it,
hardly
we
see
12
websites
which
are
supporting
on
dual.
H
Style,
I'm
not
able
to
move
yeah.
Thank
you.
So
if
you
look
at
these
websites,
they
are
the
top
ranks
website
of
six
different
categories.
And
if
you
look
at
this
commerce
and
shopping
okay,
these
top
10,
none
of
them
is
ipv6
support.
That
means
these
websites
are
running
only
on
ipv4,
and
this
report
is
like
no,
we
have
taken
in
september
right.
H
H
Now
we
did
the
same
analysis
within
year
back
okay,
wherein
in
one
year
previous
year,
2019
july,
only
11
sites
supporting
ipvc
a
dual
stack.
Now
it's
12
sites
just
one
year,
one
more
site,
and
if
you
look
at
how
much
time
is
going
to
take
even
to
move
these
two,
the
same
will
take
like
almost
40
years,
and
this
is
definitely
because,
when
the
web
web
content-
provided
they
don't
see
the
priority,
they
don't
see
that
they
need
to
migrate
ypv6,
and
that
is
the
reason
it
is
extremely
slow.
Progress
on
contents.
Moving
to.
H
Ipv6
now
some
of
these,
what
we
think
as
a
possible
solution
to
move
from
the
current,
whether
it
is
a
ipv4
or
dual
stack
to
ipv6,
only
the
sealet
compliant,
where
we
have
seen
even
the
chipsets,
where
it
is
failing
compliance
to
6877
rfc.
So
those
chip
sets
which
are
currently
used
by
mobile
industry
by
oems
by
manufacturing
industry
how
they
can
adapt
to
the
chip
service
supports.
We
don't
see,
rally
driver,
but
since
we
being
an
operator,
we
really
work
with
them.
H
H
Second,
is
the
sim
firmware
where
like
how
we
can
make
the
changes
from
ipv4
to
even
ipv4
v6,
using
tcp
based
connection
to
the
sim
okay,
so
this
also
requires
some
of
the
dependency
which
you
have
with
the
sim
chipset.
We
are
working
with
the
same
suppliers
and
then
we
are
making
them
okay
next
phase.
They
make
sure
that
they
have
impact
support
with
the
right
firmware
so
that
we
are
able
to
make
the
changes.
H
We
don't
really
bank
on
the
sms
based
impact
modification,
because
that
is
not
reliable
in
case
first
sms
goes
delete
the
firmware
and
then,
if
the
second
sms
is
not
delivered
because
of
any
region,
then
we
lose
the
military.
So
we
really
rely
on
make
sure
that
we
do
the
modification
based
on
the
secured
communication,
with
the
same
so
that
we
don't
lose.
H
The
third
point
is
that
the
macd
I
think
is
this
is
also
a
good
initiative
by,
in
fact,
standard
bodies
by
itf
to
come
out
with
rfc
and
then
in
platform
make
this
one
also
a
feasible
option.
Now
what
we
look
at
it.
H
Our
view
for
this
map
t
is
that,
since
this
is
a
option
where
we
assign
public
ipv
ipv4
along
with
the
port
range
to
every
client-
and
we
have
to
make
sure
that
we
allocate
the
static
fortrans
to
every
every
client
based
on
the
highest
number
of
port,
we
use
by
any
subscriber
suppose
somebody
because
he's
running
some
shower
cafe.
He
has
so
many
clients
and
he
has
a
big
fat
pie.
So
he
has
a
teeth
ring.
So
all
this
we
need
more
number
correction,
yeah,
okay,
one
thousand.
H
H
But
when
we
compare
with
any
career
grid
net
where
the
dynamic
port
allocation,
we
really
consume
ports
and
ip
addresses
based
on
which
are
really
required,
but
here
it
has
to
be
free
provision
pre-reserved.
So
this
is
one
challenge
which
we
see
it
requires
that
we
have
to
have
more
ipv4
ipv4.
H
We
don't
have,
we
have
to
purchase
from
investing,
so
it
becomes
a
commercially
challenging
option
to
improve,
buy
additional
ipv4
one
challenge
which
we
see.
Second,
I
guess
every
country
has
certain
regulatory
requirement
for
the
user
traceability
and
since
map
t
it
has
a
stat
state,
full
net
translation
on
the
cp
device,
the
private
ipv4
to
public
ipv4,
but
on
the
br
in
the
network.
H
Okay,
we
have
to
do
from
that
six
to
four.
So
again,
it
is
a
d
encapsulation,
okay
of
the
ipv6
packet,
okay
to
ipv4
and
selling
to
the
internet,
and
that
is
a
stateless
when
it
becomes
stateless,
you
are
not
able
to
generate
any
impact
on
that
event
logs
now,
when
the
regulator
somebody
has
done
misuse
of
the
services
and
where
our
regulator
comes
and
asks
who's
that
user.
Okay.
H
Now
we
provide
static
mapping
based
on
the
ipn
port,
okay,
which
we
say
this
is
what
we
have
provisioned
that
is
not
entertained
by
court
of
law.
Code
of
law
says
there
should
be
a
log
generated
in
the
system
by
the
system,
while
user
is
using
your
service,
the
law
should
be
used.
That
log
should
say
what
is
the
ip
address?
What
is
the
port
number
which
you
use
since
the
br?
H
H
B
H
Is
yes,
we
are
definitely
working
at
the
same
time.
It
requires
even
for
the
industry
to
come
up
to
the
level
where
all
these
new
devices
are
coming.
We
have
to
really
control
from
the
source
itself
that
once
it
is
developed,
sold
brought
in
the
market
and
sold,
somebody
will
buy
it
okay
either
it
is
bought
it.
H
That
device
has
to
work
in
the
network
and
then
operator
has
a
challenge
to
ensure
the
device
should
work,
and
that
is
where
he
has
to
fall
back
when
from
ipv6
to
12
style,
if
dual
stack
ypv
so
there's
a
continuous
md.
So
all
these
ipv6
compliant
device
readiness
application
readiness.
It
has
to
be
really
controlled
from
the
source
itself.
I
Okay,
ramesh
you've
got
a
couple
of
people
in
the
queue.
Let
me
give
them
an
opportunity.
I
Question
eric.
K
H
A
K
Yeah
go
ahead,
please,
okay!
So,
as
I
said
interesting
talk
and
nice
to
see
the
progress
you
made
since
we
met
in
paris
in
two
years
ago,
or
something
like
that
last
night,
I
have
a
questions
on
this
silla
thing
and
the
chipset.
K
I
would
assume
that
the
the
client
part
of
the
the
the
nut
is
done
in
software,
so
I
wonder
why
the
chipset
so
for
me,
hardware,
has
an
impact
on
this.
H
What
is
the
feedback?
We
are
getting
from
multiple
softwares,
where
they
have
used
the
effect
and
that
shifted
required
current
programming
and
these
oems,
whatever
programming
they
do,
they
are
open,
but
they
say
that
they
have
collected,
cannot
in
fact
use
ipv6,
and
they
cannot
program
this
to
make
impact
dual
stack
ready.
H
H
We
really
don't
know
what
level
of
programming
when
they
do
it,
but
many
of
them
we
are
able
to
convert
them
to
make
it
ready
on
the
flight.
So
then
what
we
did
it.
We
did
reverse
analysis.
Let's
look
at
the
chipsets,
okay,
what
we
have
seen
it?
If
suppose,
there
is
a
chipset
limitation,
then,
if
that
chipset
used
by
motorola
by
nokia
by
even
any
other
impact
now
the
oem,
then
everybody
should
have
exactly
the
same
challenge
there.
There
also,
I
found
a
variation.
H
Does
not
work,
so
definitely
it
is
one
is
the
capture
tissue.
Second,
is
any
additional
programming
which
is
used
by
the
oem.
Okay
is
also
making
certain
difference,
so
that
is
the
reason
second
part
of
the
oem.
We
have
the
certain
commitment.
Yes,
they
can
impact,
make
sure
wherever
they
can
do
it,
they
will
enable
it
but
others,
because
of
dependency,
because
the
chipset
with
the
use-
and
they
say
the
device-
is
going
to
be
end
of
life
in
the
process
of
reaching
it
out.
K
Okay,
see
you
cannot
train
for
me,
but
I'm
trusting
you
on
this
one
and
if
you
don't
mind
another
questions
about
the
map,
t
part
and
specifically
the
the
nut
logging.
Basically,
since
in
map
t
part
of
the
translation
is
done
statefully
on
the
cpe.
It
is
basically
the
same
if
you
do
the
translation
on
the
cpe
towards
map
t
as
well
as
going
from
the
cp
to
another
ipv4.
K
H
Yeah
sure
so
what
it
requires
is
here.
Cp
can
also
generate
the
nat
which
is
stateful
and
then
that
that
may
be
good
enough.
But
what
the
challenge
with
operator
face
is
that
we
have
millions
of
devices.
We
have
to
collect
this
log
from
millions
of
sources
and
for
some
reason,
okay,
if
I
miss
that
log
and
then
if
there
is
a
misuse.
H
If
I
miss
that
log
operator,
we
find
difficult
to
impact
or
fulfill
our
obligations
and
regulatory
compliance,
so
we
may
have
a
difficulty
in
collecting
these
logs
for
regular
requirements
from
millions
of
sources
rather
than
going
for
millions
of
sources.
That
is
where
we
want
to
do,
because
all
these
devices
are
unmanaged
device.
They
are
not
managed
by
operator,
they
are
not
in
control
of
the
operator.
H
So
that
is
where
we
bank,
on
the
device
where
we
are
responsible.
We
are
banking,
our
own
device.
That
is
where
we
thought.
If
it
is
available
on
the
br,
where
provided
managed,
integrated
controlled
by
operator,
then
we
really
don't
have
dependency
on
the
millions
of
the
devices,
and
that
is
where
we
have
a
challenge
to
use
this
nad
event.
From
the
cp,
okay
and
taking
this
log
managing
them,
it
is
not
really
not
very
practical,
because
all
these
are
unmanageable.
K
L
Can
you
hear
me
I
can
hear
you
fine
yeah.
Thank
you.
Actually,
my
questions
were
were
basically
what
eric
said,
but
I
I
can
say
something
something
else
about
that:
the
silat
problem.
I
think
it
it.
L
It's
not
really
a
set
problem
and
it's
more
the
typical
problem
of
vendors
willing
to
sell
a
new
product
instead
of
solving
the
problem
with
firmware
or
a
software
update
or
something
unless
the
problem
is
that
the
chipset
is
doing
not
four
six
by
hardware
and
then
they
cannot
do
let's
say
full
full
hardware
process,
but
considering
the
the
performance
of
the
actual
cpus.
I
don't
think
that's
a
problem.
L
It's
it's
not
really
a
a
huge
processing
capability
or
or
creating
a
lot
of
battery
consumption,
or
something
like
that.
I
am
not
really
sure,
but
I
found
similar
situations
in
cpes
and
basically
it
it
comes
to
to
the
problem
of,
as
I
just
said,
the
vendor
not
willing
to
to
update
the
firmware.
That's
one
thing
regarding
the
the
macd
problem:
I
think
it's
it's
not
a
protocol
problem.
It's
it's
more
regulation,
misunderstanding
of
how
protocols
work
and,
of
course
the
solution
will
be
go
away.
H
Yeah
thanks
for
your
comments,
so
maybe,
if
I
can
comment
on
both
the
points
one,
yes,
you
are
absolutely
right
on
the
cloud
functionality
in
the
device
when
we
use
this
impact
mode:
translation
from
4
to
6.
Definitely,
the
additional
cpu
cycles
additional
resources
required,
and
it
is
going
to
consume
additional
power
cycle
also,
so
definitely
it
is
required.
H
So
there
is
a
reason
they
don't
want,
english,
where
you
are
you're
right.
We
also
have
exactly
the
same
experience.
They
don't
want
to
invest
something
which
is
not
very
long-lasting.
So
that
is
the
one
reason
which
we
see.
Yes,
that
is
right
coming
to
matthew
my
understanding.
Yes,
there
could
be
little
variation
change
in
the
reality
requirement
in
different
countries,
but
in
normal
circumstances,
in
95
percent
of
the
cases.
Okay,
there
is
no
problem.
Okay,
everything
works
well,
whatever
the
log
we
get,
but
when
the
typical
cases
happen,
some
major
incident
happens.
H
Okay
in
any
country,
like
you
know,
even
in
india,
also
happened.
There
was
a
taj
hotel
and
attack
okay
like
terrorist.
In
such
cases,
okay,
the
mapping
which
we
provide
is
not
really
entertained
by
the
code.
What
code
says
we
need?
Okay,
the
log
is
to
certify
that
okay,
this
event
is
generated
by
this
prospect
user
system.
At
that
moment,
where
time
is
time
should
see
it
is
generated
by
that
user.
H
Okay
mapping
doesn't
work,
a
mapping
table
which
we
give
it
doesn't
work
under
the
static
information
which
is
available
and,
if
you
remember,
deterministic
that
which
came
in
the
industry
almost
six
seven
eight
ten
years
back,
that
did
not
go
forward
because
of
the
same
reasons,
regulatory
so.
Similarly,
that
is
where
we
find
them
in
the
marty,
also
that
it
works
in
99
cases,
but
operator
cannot
take
a
risk
when
one
serious
issue
or
serious
incident
which
happens
at
that
time.
You
know
the
operator.
F
H
I
J
Lorenzo
press
button-
oh
sorry,
I
forgot
to
press
the
button
just
wanted
to
say
for
464x
lad.
I
think
the
if
you're
talking
about
android
there's
performance
requirements
in
the
in
the
compatibility
definition
document
that
say
that
the
the
device
must
be
able
to
do
ipv6
only
on
mobile
networks.
J
So
that's
something
where
you
can
tell
that
the!
If
an
oem
has
an
implementation
that
doesn't
work,
you
can
point
out
to
them
that
they're
in
violation
of
the
compatibility
document,
and
I'm
also
curious
about
these
chipsets,
because
android
does
have
a
software
implementation
of
464x
lat.
In
fact,
it
has
two
one
of
them
is,
is
in
pure
software
and
the
other
one
is
accelerated
using
bpf
because
it
performs
much
better.
So
I'd
be
curious
to
hear
maybe
privately,
you
know
what
problems
you're
seeing
with
these,
because
is
this
supposed
to.
I
I
Ramesh
the
information
you're,
giving
I
think,
is
very
good
and
very
useful
and
so
go
ahead
and
speak
to
your
slides.
But
I
need
for
you
to
power
through
this,
because
we've
got
four
more
talks
behind
you.
H
H
So
other
I
think,
two
three
slides
what
we
considered
may
not
be
exactly
related
to
ipv6.
Only
what
we
also
see
like
you
know,
timing
and
synchronization,
for
example,
even
industry
today,
wherever
they
are
providing
impact
now
freeze
and
frequency
for
a
tdm,
lte
operator
network
we're
using
1588v2
by
default
profile.
H
G.8275.2
has
also
come
up
and
the
multicast
profile,
which
is
a
two
cent
5.1,
is
also
ready,
and
that
is
also
option
available.
Now,
definitely
that
multicast,
it
is
full
on
fast
support
and
in
between.
If
there
is
any
device
where
is
not
supporting,
we
cannot
really
use
it
and
the
way
it
is
implemented.
1588
v2.
We
want
to
really
in
case.
If
we
have
a
option
to
go
with
a275.2,
we
don't
see
that
the
ptp
currently
supported
on
ipv6.
H
It
is
only
on
ipv4,
so
there
is
one
area
what
we
see
possibly
need
attention
how
we
can
make
in
case
if
industry
is
really
looking
at
to
move
from
and
deploy
it
to
send
5.2
then
then
definitely
ptp
or
ipv6
required
even
for
1588v2
and
when
other
set
of
operators,
they
don't
see
any
region
to
migrate
and
they
are
happy
to
continue
1580
at
v2.
Then
also,
I
think
industry
need
that.
Okay,
it
should
be
supported
on
ipv6.
H
I'm
not
sure.
If
there
is
any
group
any
somebody,
some
trough.
H
Second
is
even
in
the
network,
for
example,
we
are.
We
have
implemented
1588
v2
in
hybrid
mode,
every
router,
acting
as
a
bc
in
hybrid
mode,
providing
impact
phase
and
frequency
to
the
slide,
low
and
assume
that
link
is
of
110
gig
and
for
business
reason.
I
have
to
upgrade
the
link
from
110
gig
to
2
into
10
gig,
and
we
have
to
create
a
bundle.
H
H
So
if
we
have
1588v2
in
unity,
cost
profile
we
continually
use.
Lsep
ecmp
is
another
option
which
is
available,
but
ecmp
also
has
many
of
the
challenges,
because
many
of
the
l2
traffic
which
we
has
and
that
is
not
going
to
be
shared
eric,
is,
I
think,
in
the
call,
maybe
even
earlier
so
that
has
its
own
challenges.
So
what
we
look
at
it?
Yes,
if
1580
is
this,
1588
v2
is
going
to
stay
in
the
industry
and
we
have
to
increase
the
capacity.
H
So
this
is
one
area.
Second
interface,
business.
I
think
that
is
some.
That
industry
is
something
which
is
moving
slowest
okay
and
it
is
not
really
a
technology
limitation.
That
is
what
we
realize
and
we
are
aware,
but
it
is
more
of
a
we
don't
see,
really
real
motivation
for
them
to
move
towards
cyclists
and
because
their
contents,
they
remain
an
ipv4.
That
is
where
all
of
the
industry
has
to
be
pushed
back.
Okay
to
stay
on
ipv6,
so
we
have
to
really
come
out
something
differentiated,
some
options.
H
Some
services,
like
you
know,
and
those
services
are
available
only
ipv6
if
that
can
attract
the
enterprise
houses
to
move
ipv6.
If
that
is
something,
maybe
it
can
work,
but
yes,
it
may
not
really
go
from
a
commercial
and
business
reasons,
but
we
don't
really
other.
We
don't
find
any
other
use
case.
How
do
we
really
motivate
enterprise
houses
to
migrate.
H
And
control
plane,
I
don't
think
there
is
a
problem,
because
srv6
is
ready.
Now
we
are
also
in
process
of
implementation.
If
we
do
it
ldp
over
v6
in
fact1
is
not
really
required.
So
I
think
we
are
good
to
go
with
the.
H
Services.
Okay,
so
I
have
included
this
slide
out
of
context
here
in
the
session,
the
reason
for
it.
Yes,
we
are
working
for
ipv6.
We
want
to
make
sure
okay
that
we
migrate
to
ipv6
and
shortest
possible
time,
but
at
the
same
time,
the
bigger
problem
which
I
am
facing
is
not
only
ip
b6
implementation.
H
Okay,
and
if
we
have
to
skill
network
for
more
subscriber,
we
are
running
sort
of
private
ipv4s
and
we
are
using,
like
you
know,
rfc
1918,
6598,
okay,
we
have
a
20
million
ip
addresses
and
we
have
divided
or
like
no
jio
network,
into
like
no
26
telecom
circles
and
every
circle
we
try
to
reuse
the
same
ip
addresses.
We
have
done
it,
okay,
the
one
time
we
have
done
it
now
in
one
circle,
I
have
a
more
than
20
million
subscribers.
H
H
H
Many
of
these
rfcs,
where
we
see
like
zero,
zero,
eight,
which
is
like
11
22
rfc,
mentioned
about
all
these
127.00.
Only
one
ip
address
used
remaining
is
made
in
fact
not
routable.
Similarly,
240
series,
okay,
256
millions
again,
these
are
reserved
the
result
I
don't
know
for
for
when
and
for
what
purpose?
H
Do
we
really
need
to
keep
them
reserved?
Is
there
time
now
to
open
them
and
make
them
available?
Okay
for
the
operators
to
use
it
and,
of
course,
when
the
operator
to
use
it,
it
has
to
be
supported
by
the
oems
on
the
platform
and
for
them
they
have.
They
need
a
standards,
they
need
rfc,
okay,
what
rfc
they
need
to
comply
to
make
these
ip
addresses
routable
in
the
network,
then
only
operator
can
use.
H
So
we
are
really
facing
a
much
bigger
challenge
in
managing
the
private
ip
industries
and
we
are
shortage
of
private
ipads,
and
that
is
where
I
in
there
is
one
or
two
other
occasions,
even
with
the
ethnic
we
raise.
This
concern.
Okay
and
very
don't
know,
is
there
any
really
serious
effort
required
to
release
some
of
the
ipv4
for
private
use?
H
And
if
this
is
enabled,
I
think
we
have
much
better
scalability.
It
is
not
that
okay
by
enabling
this
we
are
going
to
slow
down
ipv6.
No,
definitely
that
will
continue.
At
the
same
time,
it
will
bring
sudden
simplicity
and
scalability
to
operator
network
by
providing
additional
ipv4
for
private
purposes.
H
I
think
this
is
all
about
this
content,
which
I
wanted
to
cover,
and
we
can
have
plan
and
clarification,
queries
and
answers.
I
Okay:
okay,
thank
you
very
much
ramesh.
I
think
we're
gonna
have
to
take
the
discussion
of
your
talk
to
the
list,
so
I
hope
you're
you're
on
the
list
and
can
respond
to
that
or
can
can
participate
in
that
ron
who
have
we
got
next
is
that
fernando.
A
Yes,
I
think
packets,
with
extension,
headers.
J
I
Okay,
so
a
point
to
the
remaining
talks,
fernando
you're,
one
of
these
we
have
just
about
an
hour
left
and
so
we're
gonna
you've
got
15
minutes
yeah.
I
apologize
for
that.
But,
okay,
fernando,
can
you
hear
me?
Yes,
I
can.
B
Hear
you
cool
so
good
morning
after
room
wherever
you
are
so
I
will
be
presenting,
I
will
be
providing
a
status
update
of
this
document.
This
presentation
is
going
to
be
like
very
short.
Hopefully
what
is
this
document
about?
Well,
it's
a
document
that
provides
an
overview
of
the
operational
and
security
implications
of
ipv6
extension
headers
and
it
tries
to
document
to
document
the
reason
for
which
some
operators
may
drop
packets
that
contain
ipv6
extension.
Headers
next
slide.
B
Okay,
so
this
is
a
summary
of
the
changes
that
we
have
incorporated
into
the
latest
revision
of
the
document.
Essentially,
we
added
a
background
information
section
where
we
it
had
been.
We
have
been
told
that
you
know
for
some
people
the
differences
between
or
the
differences
between,
the
packet
structure
in
ipv4
and
ipv6.
Wasn't
that
clear
and
that
it
would
be
good
to
have
a
section
that
briefly
compared
the
structure
of
the
two
of
of
the
packet
structure
of
the
two
particles
and
their
implications.
B
So
that's
what
we
did.
We
also
added
a
section
on
recirculation
and
finally,
we
added
sections
on
firewalls
and
network
impression
detection
systems.
As
you
know,
two
possible
devices
that
might
need
to
resort
to
dropping
ipv6
packets
when
they
contain
extension.
Headers
next
slide.
B
So
this
document,
the
working
group
last
call
for
this
document,
was
performed
and
completed
on
november.
The
second
this
year
and
our
take
as
authors
is
that
we
it
should
be
in
shape
to
ship.
So
I
don't
know
if
there
are
any
comments.
Questions.
F
M
M
I
missed
the
working
group
last
call,
but
I
can
respond
now
or
in
its
last
call,
and
the
problem
I
have
with
it
is:
there
are
several
places
where
the
implications
seem
to
suggest
the
way
the
ietf
should
go
forward
and
operators
should
go
forward,
so
there
are
hints
that
maybe
extension
headers
should
be
disabled.
M
Firewalls
should
have
rules
in
that
prevent
them.
I'm
not
sure.
I'm
happy
with
that.
I'm
very
happy
with
the
document
saying
that
there
are
observations
of
this,
and
this
is
something
you
have
to
be
aware
of
and
we
have
to
design
for,
but
I'm
unsure
the
exact
wording
is
perfect.
I
mean
maybe
you've
had
thoughts
on
this.
B
Well,
certainly,
the
wording
might
not
be
perfect.
I
have
for
the
most
part
being
having
the
editing
pain
on
the
document
and
well.
English
is
a
second
language
for
me,
so
it
could
very
well
be
the
case
that
you
know
the
wording
might
be
improved.
If
you
have
suggestions
on
that,
please
do
send
them.
They
would
be
of
use
and
as
a
clarification
we
certainly
you
know,
do
not
want
to,
and
you
know
have
tried
not
to
do
any
kind
of
recommendation
on
dropping
packets
with
extension
headers.
B
So
we
try
to
do
is
document
the
reasons
for
which
some
operators
drop
these
packets,
but
it's
not
our
intent
to
actually
provide
advice
on
you
know
what
to
do.
In
that
respect.
We
are
just
documenting
the
reasons
for
which,
in
some
scenarios,
and
in
some
cases,
some
devices
might
need
to
drop
them,
but
it's
certainly
not
a
recommendation.
M
M
N
A
Okay,
if
you
do
work
that
out
on
the
mailing
list,
I'll
take
a
look
at
the
final
version
and
then
we'll
send
it
on
to
the
iesg
awesome.
I
Okay,
then
I
guess
we
need
to
move
on.
So
thank
you
very
much.
N
So
can
you
hear
me?
Yes,
I
can
hear
you
yes,
okay,
good,
so
paul,
volpato,
huawei
and
I
will
be
presenting
on
behalf
of
the
authors.
So
next
slide,
please.
So,
let's
start
from
the
motivation
for
this
draft.
So
basically
we
have
seen
in
the
interest
around
ipv6.
There
is,
for
example,
a
new
white
paper
by
etsy
that
let's
say
he
discussed
the
advancement
in
ipv6
deployment,
some
best
practices
to
move
it
on
even
further,
so
we
decided
to
bring
let's
say
this
topic
in
the
atf
having
two
targets.
N
N
N
Right
there
are
a
lot
of
analytics
worldwide
available
for
ipv6.
The
whitepaper
of
etsy
I
just
mentioned,
provides
the
full
list
of
references.
We
have
put
here
just
a
small
subset
to
give
a
rough
indication
about
the
status
of
ipv6,
so
we
can
see
from
the
number
of
users
or,
for
example,
from
the
allocations
that
ipv6
has
grown
quite
well.
I
would
say
in
the
last
five
years
and
what
is
most
important:
it
has
grown
more
than
ipv4,
so
this
is
a
good
say
signal
to
the
industry.
N
Now,
when
preparing
the
white
paper,
we
also,
let's
say,
develop
the
short
survey
to
be
distributed
to
the
operators
supporting
that
effort
or
involved.
Let's
say
so.
You
see
the
list
of
questions
we
post,
for
example,
the
plans
to
move
on
with
ipv6
in
the
next
two
years.
What's
the
favorite
technology
and
other
information
useful
to
say,
understand
the
status
of
ipv6.
N
The
draft
also
discusses
the
answers,
but
basically
just
to
again
try
to
figure
out
the
rough
indication
of
ipv6
and
the
the
real
world
deployments.
You
see
that,
for
example,
operators
tend
to
adopt
the
dual
stack
as
the
first
approach
to
ipv6
and
then,
when
the
conditions
are,
let's
say
well
are
good
enough:
they
move
to
ipv6
only,
and
there
is
a
slight
preference
for
xlat
in
the
mobile
space
and
dual
stack
light
for
fixed
services.
N
These
incentives
can
be
different.
Of
course,
there
is
a
technical,
let's
say
a
list
of
incentives.
For
example,
somebody
in
the
survey
responded
that
it's
thanks
to
the
endorsement
of
ipv6
from
iatf
or
other
bodies
that
there
is
a
let's
say,
a
a
new
wave
of
adoption
of
ipv6.
N
Right
and
here
we
come
to
the
what
we
refer
to
as
the
call
for
action.
So
what
are
the
challenges
that
we
probably
need
to
face
to
have
a
full
adoption
of
ipv6
and
create,
let's
say
the
conditions
for
the
acceptance
in
our
industry
again,
depending
whether
you
are
a
part
of
a
service
provider
or
enterprise,
the
motivations
may
change,
so
the
scope
could
be
different,
but
actually
we
found
some
areas,
for
example
the
transition
choices.
N
There
are
technical
aspects
to
be
phased
and
to
be
solved
to
have
the
deployment
of
ipv6,
for
example,
for
a
service
provider.
With
the
issue
of
having
cgnet
and
the
transition
to
move
forward
this
technology
for
enterprises,
we
have
found
that
some
of
them-
or
I
would
say
many
of
them-
have
failed
to
adopt
ipv6
because
they
think
it's
too
complex.
They
don't
have
the
expertise
in-house
to
do
so.
N
N
Please
then,
there
are
also
operational
aspects,
so
you
see,
for
example,
performance.
We
know
that
ipv4
and
ipv6
are
not
the
same
thing
yet
people
tend
to
compare
them
and
looking
at
some
well
documented
cases,
there
is
a
lot
of
literature
about
that.
We
have
seen
that.
N
On
average,
if
we
take
the
let's
say
a
rough
average,
ipv4
is
still
probably
faster
than
ipv6,
so
latency
tends
to
be
higher
for
ipv6.
There
are
some
documented
explanations
for
for
that
number
of
studies.
And
again,
if
you
take
our
draft
or
the
etsy
white
paper,
we
have
the
full
list
of
references
to
dig
into
the
matter
packet
loss.
N
N
Over
the
let's
say
the
big
internet
in
terms
of
performance
of
the
equipment,
we
have
seen
that
more
or
less
routers
are
capable
of
handling
both
ipv4
and
pv6.
Probably
there
is
only
one
slight
difference
if
we
consider
the
low
end
routers
next
one,
please
and
then
the
last
aspect,
so
the
last
challenge
is
security.
N
Again,
something
is
probably
related
to
what
the
respondent
to
the
survey
associate
to
the
level
of
complexity
of
ipv6.
So
as
such,
there
is
probably
the
misunderstanding
that
security
has
to
also
face
to
solve
that
level
of
complexity.
N
There
are
clearly
issues
related
to
the
protocols
themselves.
For
example,
we
can
differentiate
between
the
the
bunch
of
basic
protocols
and
all
the
components
that
may
affect
security,
and
there
is
a
list
of
associated
protocols,
so
icmp
neighbor
discovery
and
so
on,
and
the
third
level
of
internet
wide,
ipv6
security.
N
So
everything
which
is
associated
to
filtering
the
denial
of
services,
attack
transition
and
whatever
specifically,
it
appears
that
a
neighbor
discovery
and
the
first
hope
protocols
are
part
of
the
area
related
to
security
that
we
need
to
and
to
still
need
to
to
analyze
to
give
a
proper
picture.
So
next.
N
H
Now,
if
this
is
congested
link,
then
yes,
there
is
a
possibility
that
latency
may
be
little
higher,
but
as
you,
for
example,
in
the
network,
where
there
is
no
bandwidth
limitation,
there
is
no
congestion,
and
in
that
situation,
ipv6
should
be
faster
than
ipv4.
So
latency
should
be
lower,
because
even
the
routing
platform,
the
if
the
datagram,
which
is
sent
which
ipv6
can
carry
a
larger
datagram,
the
number
of
packets
to
be
processed,
will
be
smaller.
H
And
if
this
is
smaller,
lesser
cpu,
which
is
going
to
use,
then
router
is
going
to
be
consuming
lesser
time,
and
this
is
going
to
save
little
cpu
cycle
little
extra
time,
which
can
save,
which
possibly
can
compensate
even
the
propagation
and
the
propagation
is
like.
No,
it
is
a
just
a
speed
of
light
in
the
optics.
H
N
Sure
thanks,
so
there
are
a
lot
of
studies
that
I
would
say
proves.
N
H
N
N
F
N
N
I
I
mentioned
the
survey
in
the
draft,
but
any
further
input
or
feedback
is
welcome
and
for
enterprises
just
to
as
they
mention
that
intc
and
the
indian
internet
engineering
society
are
two
organizations
working
on,
let's
say
the
the
enterprise
domain.
N
F
I
Is
it
for
me,
okay?
Well,
thank
you
very
much
and
I
think
we're
going
to
have
to
take
the
comments
to
the
list
and
people
who
want
to
comment
on
this
drop
note
to
the
list,
and
I
will
drop
a
note
indicating
how
to
reach
intc
and
india
icehawk
for
yeah
I
suck
shipping
did
you
want
to
get
in?
Oh,
okay,
yeah.
You
want
to
make
a
presentation.
G
Hi
hi:
this
is
shubing
from
huawei
and
I
would
like
to
discuss
about
the
precision
of
the
hall
by
hub
options.
Header
first
about
the
motivations
and
it's
we
know
the
ipv6
is
being
widely
deployed
and
more
more
and
more
ipv6
based
on
new
services
are
being
proposed
and
the
how
behalf
options?
Header
is
being
taken:
a
very
valuable
container
for
carrying
some
information
to
facilitate
those
new
services
and
among
all
the
extension
headers
ipv6
extension
headers.
The
hub
hub
options.
G
G
That
is
because
then
the
hubble
hub
options,
header,
has
been
taken
as
a
potential
dos
attacker
and
the
operator
is
basically
want
to
protect
this,
their
control
plane
from
the
undesired
traffic,
and
we
had
some
discussions
in
the
mailing
list
of
the
six-man
working
group.
G
G
That
is
also
a
recent
work
being
adopted
in
the
six-month
working
group,
so
they
all
have
the
valuable
they
are
all
valuable.
They
have
the
valuable
cases
and
a
very
interesting
use
cases
to
the
operators.
G
Okay,
so
now
I
will
start
from
the
modern
router
architecture
as
specified
in
the
rfc
6192,
and
we
can
see
that
there
is
a
strict
separation
between
the
control
and
the
forwarding
plane
in
a
router.
So
the
control
plane
basically
is
generally
is
realized
in
a
software
general
purpose
processors
and
they
are
running.
They
are
responsible
for
running
the
routing
and
the
management
functions
and
they
are
very
vulnerable
to
the
dos
attack.
G
G
So
in
between,
there
is
the
interface
so
generally,
there
will
be
a
read
limit
mechanism
implemented
and
for
the
purpose
of
protecting
the
control
plan
against
the
and
that
the
undesired
the
traffic
and
to
against
the
dos
attack.
So
that
is
a
good
thing,
but
there
are
also
sad
effects.
It
will
cause
the
inconsistent
drop
packet
packet
drop
because
of
this
read
limiting
and
that
will
impact
the
normal
ip
forwarding,
not
even
to
support
the
new
services.
G
So
now,
let's
look
at
the
common
implementation
and
so
on
the
right
side,
part,
and
that
is
the
the
specification
in
rc820
8200
that
defines
the
format
and
we
can
see
so
actually
in
the
comment.
Implementations,
the
value
of
the
next
header
field
in
the
ipv6
header
is
actually
the
only
trigger
for
the
default
precision
behavior
of
the
hubble
hub
options,
header
so
for
the
common
implementations
in
most
of
the
devices
in
the
market
that
is
once
the
the
device
receives
the
ipv6
package.
G
G
So
all
the
package
containing
hobby
hub
will
just
be
dispatched
to
this
slow
pass.
The
control
plan
that
will
cause
the
dos
attack
on
the
control
plan
and
the
read
laymate
will
cause
the
inconsistent
packet
drops
and
also
since
there
are
a
lot
of
routing
and
the
management
functions
running
there,
they
are
very
critical.
G
G
G
So
it
seems
that
we
are
actually
facing
endless
loop.
G
That
is
starting
with
the
implementation
choice
and
which
calls
the
hardware
hub
to
become
a
dos
vector
and
because
the
hardware
hub
is
taken
as
a
dos
vector,
the
network
operators
will
deploy
the
acl,
and
that
discussed
the
package
containing
hubba
hub
and
because
operator
is
doing
this.
And
then
the
network
designers
just
stopped
defining
the
new
hub
options
and
because
of
this,
the
community.
The
community
wasn't
motivated
to
fix
the
problem.
G
G
And
here
just
a
few
points
to
show
the
desire,
the
precision
behavior
and
we
would
like
to
discuss
with
you
and
get
feedback,
and
the
first
principle
is:
the
control
plan
should
be
protected
from
the
undesired
traffic.
So
that
is
the
hub
options
that
are
not
supposed
to
be
processed
by
the
control
plan.
Shouldn't
be
sent
to
the
control
plan
and
also
the
hubba
hub
options.
G
G
I
So
I'm
going
to
invite
people
whoever
they
are
from
the
working
group
to
comment
to
the
list
about
your
draft
so
that
we
can
formulate
a
response
back
to
six
men
and
and
obviously
so
that
you
can
see
the
comments
as
well
and
that's
obviously
going
to
be
offline.
We're
not
going
to
be
able
to
do
that
today.
O
Much
hi
this
is
geon.
Can
you
can
you?
Can
everyone
hear
me
yep
all
right,
so
I'll
I'd
like
to
present
the
strap,
so
it's
slack
with
variable
prefix
length,
a
problem
statement
we
have
had,
I
think,
over
the
last
week,
or
so
quite
a
number
of
email
threads
related
to
this.
That's
that
spawned
quite
a
bit
of
interest.
O
So
thank
thanks
ron
on
so
from
from
the
the
first
set
of
threads.
I
guess
they
came
about
oled
grace
we
put
to
graciously
put
together
a
list
of
options
to
extend
slash
64.,
so
all
of
those
various
options,
the
two
that
we're
going
to
talk
about
in
this
slide
deck
is
b1
which
is
64
share
and
which
is
the
option
that
cameron
had
mentioned.
O
I
guess
and-
and
it
spawned
quite
a
number
of
threads
related
to
how
64
share
could
be
used
to
extend
64
from
for
mobile
3gpp
and
then
option
h
in
this
in
this
list
here
variable
slack.
So
that's
really
the
problem
statement
really
that
we
have
referenced
in
this
slide
in
in
the
draft
and
and
the
problem
that
we're
stating
here
so
that
that's
basically
h.
Next
slide.
O
So
this
this
slide
basically
states
the
problem
statement,
that's
described
in
the
draft
and
it's
really
basically
extending
the
further
segmenting
a
64,
that's
received
from
the
from
the
3gpp
from
the
land
and
extending
it
down
to
other
devices
within
within
within
the
network.
And
there
are
various
different
scenarios:
a
vehicle,
the
vehicle
scenario
where
you
receive
the
slash
64
from
the
cellular
and-
and
you
have
other
downstream
devices
that
you
want
to
segment
and
they're
they're
in
the
draft.
O
It
does
describe
a
couple
different
scenarios
where,
in
the
vehicle,
the
vehicle
scenario
where
you
have
different
link
types
of
like
some
devices,
maybe
on
bluetooth
or
whatnot
or
different
device
types,
and
you
want
to
extend
that
slash
64.
but
had
but
had.
But
the
really.
The
problem
is
because
the
slash
64
is
not
has
that
fixed
boundary
you're
not
able
to
extend.
So
what
this
draft
does
is
describes
that
that
issue,
that
if
we
were
able
to
have
a
longer
prefix
length,
allow
and
not
have
that
fixed
64-bit
boundary.
O
You
would
be
able
to
take
that
64
and
extend,
and
and
as
shown
here
in
red,
like
65
down
to
devices
kind
of
further
segmented
segmented
down
into
the
into
the
customer
network.
Next
slide.
O
So
this
is
the
64
sheer
v2
scenario
that
was
discussed
by
carmen
that
he
had
brought
up.
O
He
had
put
together
an
updated
version
of
the
64
shear
draft,
so
this
was
an
interesting
method
of
I
guess
it
was
called
trickery
of
how
you
can
take
that
slash,
64,
but
somehow
extend
you
know,
you
know,
go
with
shorter
prefixes,
so
I
think
that
the
tricky
part
with
the
3gpp
that
it
because
it
does
not
support
dhcp
v6
you're,
not
able
to
get
shorter
prefixes
but
with
using
64
share
v2
with
64,
share
the
concept
you're,
stealing
the
you're,
basically
doing
rapd
and
stealing
the
wan
64
and
using
it
and
subtending
it
down
to
devices
within
your
within
the
customer
edge.
O
So
with
that,
I
think
with
this
with
this
memo
and
this
draft
update,
it
would
request
3gpp
to
change
their
requirement
to
allow
any
prefix
size
so
less
than
64
to
be
advertised
from
the
3gpp
gateway
to
the
ra
to
the
to
the
handset
device,
the
mobile
device.
O
So,
for
example,
a
56
or
even
you
know
smaller
shorter
blocks.
You
know
possible.
The
caveat
here
is
that,
in
order
for
that
to
happen,
the
I
would
think
the
a
flag
would
not
have
to
be
set
in
the
ra.
For
that
to
happen,
or
or
with
that,
a
that
would
work,
you
know
fix
that
boundary
at
that
64-bit
boundary.
So
that
would
be
that's.
I
guess
one
caveat.
O
The
other
caveat
is
that
you
know
how
the
trickery
that
would
work,
I
guess,
would
work.
I
guess
on
the
3gpp
side
is
when
they
be
able
to
without
having
the
rfc
updated
to
support
like
rfc
4291,
which
has
the
64-bit
the
64-bit
iad
requirement.
You
know
fixed
boundary,
I
my
guess
would
be
that
would
have
to
be
updated,
as
well
as
the
3gpp
architecture
to
support
the
shorter
prefix
lines.
O
So
so
that
that's
something
so
I
think
this
could
be
a
possible
solution,
but
it
would
require,
I
guess,
updating
of
the
of
our
rfc
4291,
as
well
as
the
3gpp
architecture,
to
support
shorter
prefixes
next
slide.
O
So
this
the
second
issue
related
to
the
that
that
this
draft
talks
about
the
the
problem
regards
to
the
problem
statement
and
why
longer
prefixes
should
really
be
should
be
allowed
and
is,
is
in
regard
to
the
addressing
architecture
and
and
really
the
three
methods
of
addressing
one
is
static.
O
Second
dhcp
v6
and
then
of
course,
the
third
slack
that
we're
talking
about
now
so
static
allows
for
any
any
prefix
length
of
you
know:
zero
through
128
and
so
does
dhcp
v6
slack
is
really
the
only
one,
that's
lacking.
That
does
not
allow
for
that.
So
in
this
this
disk
draft
rc
61
rfc
6164
the
previous
version
of
this.
You
know,
I
guess
historically
slash
127s
on
point-to-point
links
were
harmful
and
the
reason
for
that
was
due
to
the
overlap
with
the
the
router
anycast
ip.
O
So
with
this
draft
this
rfc
it
actually
states
that
it
is
recommended
and,
and
then
and
and
and
vendors
I
think,
will
a
bug
in
router
hardware
that
caused
a
ping
pong
effect
to
happen
that
that
it
was
not
supported.
But
now
it
is
a
recommended,
and
really
it's
a
de
facto
standard
that
you
know
most
all
operators
on
any
point-to-point
links
that
you
do
use
the
slash
127.
O
So
this
this
so
in
this
rfc
6r6164,
what's
mentioned,
is
neighbor
casting
bubble
really
comes
into
play
is
what
most
operators
do
across
the
board?
Is
you
know,
even
even
though
slack
does
not
support,
and
it
has
that
fixed
64-bit
boundary.
O
What
most
operators
do
in
ipv6
deployments
is
they
do
use
and
it's
really
used
across
the
board
is
ins
instead
of
using
a
fixed,
64
length
of
prefix
on
any
kind
of
subnet,
let's
say
infrastructure:
they
they
do
a
hard
basic,
a
hard
limit
on
the
on
the
on
the
nd
cache
by
actually
setting
the
the
subnet
size
to
the
number
of
hosts
that
you
have
an
example
would
be,
and
I
got
a
slide
further
down,
but
really
an
example
of
that
is,
let's
say
a
share
could
be
a
shared,
let's
say,
content
engine
network
or,
let's
say
a
firewall,
a
let's
say
a
firewall
pool
or
whatnot
or
let's
say
nfv
or
virtualization,
where
you
have
a
pool,
but
you
don't
want
to
have
like
a
massive
slash,
64
pool
just
due
to
the
issue
related
to
nd
cash
exhaustion.
O
I
I
Okay,
I'm
going
to
guess
that
she
has
left
there
well
he's
not
around
lorenzo.
You
wanted
to
talk.
J
J
I
think
yeah
just
just
a
little
bit
further
down,
I
think
yeah.
I
know
yeah
so.
O
One
one
more
one
more
down
one
more
next.
J
One
there
we
go:
that's
it
yeah,
so
so
you
can't
do
this
and
the
reason
you
can't
do
this
is
that
it
will
break
every
unmodified
device
on
the
planet,
because
all
the
devices
out
there
know
that
you
can
only
use
slack
on
64..
J
If
you
ever
do
this
by
mistake
to
a
legacy
device
it'll
just
not
form
an
ipv6
address,
so
think.
I
think
if
you
want
to
do
this-
and
there
was
some
discussion
about
this-
I
think
you
you
just.
We
have
to
introduce
a
new
option
of
some
sort
in
the
ra.
We
can't
use
pio
for
that
we
have
to
have.
We
still
have
to
have
a
64
pio
for
the
for
auto
comfortable.
O
O
Understood
so
so
lorenzo
that's
that's.
I
agree
with
that.
I
agree
with
what
you're
saying
I
think
what
the
gifts
would
require
for
this
to
work
is
you
would
really
have
to
update
the
rfc.
O
You
know
so
there
would
have
to
be
some
kind
of
backward
compatibility,
but
it
would
require
changing
the
standard
to
work.
I
don't
think
there's
any
way
that
it
would
work
even
with
let's
say
the
a
flag
not
set.
I
don't
think
it
would
work
and
that's
what
you're
stating,
but
it
would
break
everything.
J
Yeah
it
wouldn't
work,
I
mean
I
think
you
can
try
to.
You-
can
try
to
define
a
new
option
that
that
I
think
you
can
do,
but
you
can't
use
pio,
but
you
can't
use
the
pio
option
unless
you
can
do
something
like
two
pios
on
the
in
the
ra.
J
O
In
this
draft
that
we're
talking
about
on
this
sub
with
this
jack,
so
that
states
the
problem
statement
and
there's
another
graph
that
talks
about
a
flag
that
could
be
used
in
pio
that
actually
allows
you
to
have
a
variable
length,
prefix
and
we
have
tested
that,
like
just
on
the
linux
kernel
with
one
of
the
developers.
That's
on
the
on
this
draft
that
actually
states
that
that
that
it
can
be
done.
O
It's
just
a
matter
of
you
know
getting
the
work
group
to
adopt
the
one
that
changed
to
change
the
graph
and
really
really
the
problem
statement,
and
that's
really
the
big
one.
Whether
the
work
group
would
agree
to
changing
that
and
it
would
be
really
changing
the
standard.
The
rc
4291
breaks
that
fixed
boundary,
and
so
that's
that's
really.
The
sticking
point.
J
I
don't,
I
don't
recommend
that
you
attempt
to
change
that.
I
don't,
I
don't
think
you'll
succeed.
I
think
I
think
your
time
is
better
spent.
We
had
a
huge
bust
up
a
few
years
back
it
took
months,
and
then
we
just
had
a
lot
of
arguments
and
then
went
nowhere.
I
think
you're
much
better
off
defining
a
an
easy
way
to
advertise
a
bigger
prefix
to
hosts
like,
like
your
60
or
56
here,
and
basically
use
that
as
a
replacement
for
the
hp
pd,
for
example,
on
mobile
networks.
J
I
think
that
that's
got
a
much
greater
chance
of
succeeding
in
standard
space
and
even
in
even
in
mobile
handset
space.
It's
actually
a
lot
easier,
for
example,
for
android
to
do
this
than
it
is
to
implement
pd
for,
for
a
variety
of
reasons,
some
of
which
technical
so
much
non-technical.
So.
O
J
O
Wouldn't
accept
it
really
because
it's
going
to
try
to
build
the
it's
going
to
be
able
to
try
to
build
a
64-bit
dome,
it's
not
going
to
be
able
to
work.
I
guess
it's
not
going
to
be
able
to
do
anything
with
that
shorter
prefix!
O
That's
right!
Thank
you.
Thanks,
thanks
lorenzo
we
could
we
can
go,
go
back
to
the
other
slide.
I
guess
we
can
continue
with
the
presentation.
So
where
was
I
I
was
on
that
I
guess
go
to
that.
Nd
cash
exhaustion,
that's
kind
of
where
I
was
left
off.
O
Yeah
there
we
go
so
so
this
slide
really
talks
about.
Addressing
really
and
the
reasons
why
so
so
I
think
in
some
of
the
threads
that
we
had
on
the
mailing
list
was
regarding
operations
and
operators
and
whether
variable
length
masking
is
used
and
and
and
really
so
really.
What
the
key
point
here
is
in
this
slide
is
really
that
it
has.
It
is
used
and
it's
definitely
proliferated.
You
know
kind
of
throughout
most
operators
do
using
this
nd
cash
hard
limit.
O
I
mean-
and
it's
really
kind
of
stem
from
this
rc
that
it's
it's.
It's
definitely
used
quite
a
bit
where
and
it
depends
on
the
size
of
the
host,
and
this
is
all
static.
Addressing
that
you
know,
if
you're,
you
know
your
dual
stack
or
even
v6,
only
that
you're
sizing
the
subnet
based
on
the
number
of
hosts
that
you
plan
to
have
on
the
subnet
and
and
without
not
having
to
use
any
knobs
to
actually,
you
know
prevent
nd
cast
exhaustion
next.
O
Slide
so
in
in
this
slide,
it
actually
yeah
that
that's
okay,
yeah
yeah,
go
to
sorry.
Let
me
see
here,
go
one
up
actually
go
back
one.
O
There
we
go
yeah.
I
just
wanted
to
mention
something
that
was
mentioned
in
this
rfc,
so
it
did
does
mention
in
here
that,
even
if
you're,
even
if
you're
doing
any
kind
of
careful
rate
limiting
or
anything
with
you
know
like
any
knobs
or
tweaks,
you
know
to
to
to
prevent
the
nd
cash
exhaustion.
O
You
know
it
may
not
be
bulletproof,
and
that's
really
one
of
the
reasons
why
operators
just
to
be
sure
they
don't
want
to
run
into
problems
so
having
to
size.
A
subnet
based
on
the
number
of
hosts
on
the
subnet
has
really
been
the
kind
of
the
recommended
way
of
doing
it,
and
it's
really
because
you
know
variable
length
has
been
supported.
You
know
via
static
addressing
you
know
since
day.
One
that's
supported,
so
that's
really
been
the
mantra
of
how
to
how
to
address
you
know
for
operators
next
slide.
O
So
this
this
slide
so
rfc
7381.
It
talks
about
the
enterprise
ipv6
deployment
guidelines,
so
I'll
go
on
to
the
next
slide.
O
So
in
this
slide
just
pointing
out
that
that
slash
64.
so
with
the
64-bit
boundary,
it
is
the
recommended
that
you
know,
because
you
do
have
because
slack
devices
that
they
have,
that
fixed
eoi
64,
so
that
modified
64-bit
boundary.
So
even
though
you
may
have
stateful
or
static
dust
support,
you
know
does
support
variable
length
so
any
size
it's
recommended
for
any
host
subnets
to
use,
slash
64..
However
anything
infrastructure,
that's
statically
addressed
you
can
pretty
much
use
any
address
and
any
size.
So
you
know
from
zero
all
the
way
to
127.
O
Whatever
size
you
know
fits
the
bill
can
work.
I
Next
slide:
okay,
gian
fyi.
In
about
two
minutes,
the
media
echo
room
is
going
to
close
okay.
O
Thanks
thanks
I'll
try
to
wrap
it
up
all
right,
the
race
to
the
bottom.
Let's
see
if
you
can
race
through
the
slide
deck
all
right,
so
so,
basically,
on
this
on
this
slide,
I
just
I'll
just
kind
of
try
to
summarize
with
regards
to
the
race
to
the
bottom,
I
think
there
was
a
comparison
on
on
the
mailing
list
that
was
done
in
regard
to
history
and
now
and
and
the
reasons
why
so
that-
and
that
is
you
know-
has
been
there
forever
and
it's
really
helped.
O
You
know
at
least
extend
the
use
and
even
character
in
that
to
extend
ipv4.
So
it
has
served
its
means,
you
know
to
help
help
extend
and
it
has
helped
for
overlapping
of
address
space.
So
there
has
been.
You
know,
need
for
that,
and
it
has
served
its
purpose
so
and
even
today-
and
I
think
probably
until
v4
was
gone
completely
nat
you
know
has
its
place,
however,
comparing
so
to
the
comparison
that
was
done
on
the
mailing
list
was
related
to
nat
for
broadband
users.
O
So
so
any
in
your
broadband,
you
know
users,
where
you're
doing
a
nat
overload
that
that
carriers,
you
know,
has
been
you're
really
the
ubiquitous
standard.
That
carriers
will
actually
give
you.
You
get
a
single
ip
on
your
win
on
your
on
your
on
your
broadband
interface
and
then
and
then
basically
you're
doing
a
port
overload
and
you're
doing
it.
You're
doing
a
port
address
translation
for
forwarding,
so
you're,
really
just
getting
a
single
ip.
O
O
There
was,
even
even
you
know,
10
15
years
ago,
because
the
address
space
was
so
limited
yeah,
and
that's
really
why
ipv6
came
out
20
some
years
ago
that
we
knew
that
address
depletion
was
going
to
happen
and
that's
why
the
ubiquitous
standard
for
broadband
was
a
single
ip.
So
there's
absolutely
no
way
you
can
compare
ibv6
type.
O
You
know
ipv4
to
ipv6
and
the
reason
why
operators
went
down
to
the
race
to
the
bottom
to
give
out
a
single
ip
is,
is
an
absolutely
not
a
valid
comparison
to
why
v6
would
have
that
same
race
to
the
bottom
and
just
to
the
case
in
point
there
is
that
is
that
with
ipv6
you
have
I
mean
you
truly
have
unlimited.
I
mean
ridiculous
amount
of
space
that,
even
with
even
with
the
the
2000s
slash
three
they're,
still
unallocated
space
by
ayanna.
O
I
think
there's
like
five
other
slash,
threes
and
there's
a
bunch
more
there.
So
there
is
a
tremendous
amount
of
space
that's
available,
but
that
that
being
said,
the
question.
Another
question
that
came
up
on
list
was
well.
Let's
say
you
know
if
hypothetically
you
know,
3gpp
or
maybe
even
5,
I
guess
5g
may
be
a
different
story
altogether
with
network
pricing,
but
let's
say
that
bgp
and
54.
O
If
we
were
able
to
allow
you
know
somehow
we
were
able
to
get
a
shorter
prefix
hypothetically,
you
know
if
you
were
able
to
like
consider
a
human
allocation
of
a
slash
48
for
a
human.
Then
that
was
an
idea
that
came
up
on
list,
so
just
taking
that
theory,
you
know
to
see
if
that
even
is
even
possible.
Given
our
current
schema
of
address
breakdown,
you
know
and
how
addressing
is
deployed
kind
of
on
the
internet.
O
So
when
you
think
about
it,
when
the
iana,
when
it
reserves,
you
got
space,
that's
reserved
down
to
the
river
and
then
the
river
allocates
to
the
isp,
and
then
you
got
the
unusable
allocation.
So
the
isps
just
looking
at
the
isps,
what
they
get
in
general,
the
starting
points
at
slash
32-
and
this
is
from
jordy.
O
You
know
thank
you
for
sharing
kind
of
some
of
that
information
of
what
you
know.
What's
the
allocation
schemes
that
that
have,
you
know
been
done
by
wright,
so,
let's
say
32
by
you
know
for
general
starting
point
24
to
26
for
medium
and
then
19
to
20
for
for
large,
so
just
give
it
given
those
numbers-
and
this
is
just
a
hypothetical.
O
Even
if
you
had
a
slash
724,
you
know
and
that's
for
like
a
large
isp
that
that
would
yield
16
million,
slash,
48s
and
a
this
is,
and
I'm
just
giving
verizon
like
as
an
example,
we've
got,
we
have.
We
have
150
million
subscribers,
there's
no
way
even
with
a
slash
24,
and
that
just
covers
that
just
covers
our
3g
pvp
or
a
wireless
space
and
not
not
broadband
users.
So
there's
no
way
you
you'll
be
able
to
cover
it.
O
You
know,
without
that
amount
of
space
you
know
doing
a
slash
48
per
human.
So
granted
you
do
have
a
lot
of
space,
but
I
think
you
would
have
to
allocate
more
further
allocating
we
do.
There
are
unallocated
space
within
the
iana
that
they
would
have
to
allocate
to
do
a
48.
I
think
probably
a
56
is
possible,
but
48
to
per
human.
Since
I
did
come
up
on
thread,
I
I
wanted
to
talk
through
that
and-
and
you
know
that
definitely
would
not
be
possible
next
next
slide.
O
So
this
slide,
I
just
wanted
to
just
kind
of
emphasize.
You
know
what
operators
do
just
to
give
six
man
and
the
folks
on
on
here
really
what's
done
and
what's
reality
and
and
what's
deployed
by
operators.
So,
and
so
as
far
as
ipv6
is
concerned,
variable
length
masking
is
there
and
it's
been
it's.
It's
really
proliferated.
O
You
know
throughout
operators,
you
know
around
the
world,
slash
127.
You
know
one
point
to
point
links
on
on
ixp.
You
know
naps,
slash,
116
or
even
112s.
You
know,
but
basically
the
concept
is
really
scaling
the
size
of
the
subnet
to
this
really
the
size
of
how
many
connections
or
how
many
hosts
are
going
to
be
on
that
subnet.
If
it's
a
peering
point,
you
know
scaling
and
sizing
the
subnet
accordingly
and
not
using
the
slash
64..
That's
really
kind
of
the
bottom
line.
You're
actually
really
scaling
it.
O
So
you
have
that
hard
limit
that
hard
any
cash
flow
and
that's
really
the
ubiquitous
standard
for
really
operators
all
around
the
world
and
that
that
being
said
and
what
this
slide
also
talks
about
is
really
kind
of
the
accessory.
The
next
slide
does
let's
go
to
the
slide
and
that
talks
about
kind
of
the
problem,
the
final
problem
statement
and
then
I'm
done
with
the
deck.
O
So
this
last
piece
here
is
really
you
know
the
parity,
the
lack
of
parody
that
exists
between
between
slack
and
stateful
v6
and
static,
so
both
static
and
stateful
allow
for
basically
any
kind
of
mask
and
any
kind
of
mask
that
I've
stated
you
know
in
the
slides
earlier
is
used
really
ubiquitous
standard
across
across
the
globe.
You
know
operators
going
to
use
any
size
mask,
but
but
slack
really
has
that
really
legacy
64-bit
boundary-
that's
existed
from
day
one.
So
what
that
does
is
it
does?
O
It
does
handle
operators
from
doing
any
kind
of
any
really
you're
stuck
with
all
pushing
forward
boundaries
so,
and
it's
really
the
fear
of
having
any
any
device.
That's
slack
that
ends
up
being
that
same
subnet,
you
know,
would
not
work.
You
really
you're
you're,
basically
stuck
at
that.
Really
at
that
640
boundary
that
you
can't
do
you,
and
this
is
really
for
it.
Could
this
could
apply
to
data
centers
as
well
as
access
that
you
really
cannot
do
any
any
variable
length
masking?
O
You
can't
do
a
longer
prefix,
basically,
that
you're
you're
you're
hit
you're
you're,
basically
hampered
that
any
dhcp
v6
that's
deployed
really
anywhere
by
any
operators.
You're
really
you're,
really
using
only
a
64-bit
scope
and
then
and
then
same
same
with
static
any
static.
So
so
any
subnet
that
has
a
mix
and
you've
got
to
account
for
the
mix
that
you're
really
any
any
host
subnets
that
are
deployed
by
any
operators.
O
J
I
wanted
to
say
one
slide
back
you're
you're,
pointing
you're,
saying
that
you
could
just
you
know,
size
your
subnets
for
this
specific
number
of
hosts
that
are
on
the
subnets.
I'd
like
to
point
out
that
for
general
purpose,
hosts
like
like,
presumably
this
laptop,
that
you
have
on
the
slide,
the
best
the
best
current
practices
in
rfc
7934
say
that
it's
it's
recommended
that
network
operators
allow
devices
to
form
hoses
to
form
as
many
as
many
addresses
as
they
want.
J
So
what
this
means
is
you
can't
say,
I'm
gonna
have
eight
laptops
on
this
on
this
on
the
subnet
and
a
sinus
125,
because
the
best
practices
say
that
those
those
laptops
are
should
be
able
to
form
more
addresses.
This
is
one
of
the
reasons.
Why
also
that
that
document,
the
best
practice
recommends
against
running
a
dhv6
only
network.
J
So
I
just
wanted
to
point
that
out.
So
there
is
best
practice.
There
are
best
practices.
That
say:
don't
do
this
just
just
want
to
play
that.
O
J
O
O
Yeah
and
that's
something
that
I
think
I'm
mentioning
that
if,
if
the
standard
would
allow
like
like
variable
length
like
longer
masks,
then
then
it
could
be
different,
but
because
the
standard
has
that
64
you're,
really,
you
can't
really
change
that
everything
has
to
be
64.
O
for
hosts
for
end
hosts.
Only
infrastructure
can
do
whatever
they
want.
So
for
network
providers
routers
and
switches.
We
can
do
whatever
we
want,
but
it's
really
just
those
host
subnets
are
fixed
at
that
64.
and
there's
really
nothing.
You
can
do
about
that
unless
the
standard
changes
you
agree
with
that
lorenzo.
J
J
I
think
I
think
you
already
said
for
infrastructure.
You
can
do
whatever
you
want
right,
so
yeah.
So
if
you're,
if
you're,
if
you're
suggesting
changing
this
64-bit
boundary
limitation,
then
you
you,
you
want
to
consider
that
there
is
a
best
practice
that
says,
allow
a
host
to
form
as
many
addresses
as
they
want.