►
From YouTube: IETF99-V6OPS-20170718-0930
Description
V6OPS meeting session at IETF99
2017/07/18 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
A
A
A
Okay,
Soviet
come
on
Ian
guys
have
a
seat,
so
this
is
the
agenda
that
we
have
today.
We've
got
if
you
think
of
our
slot
today
and
Thursday
is
a
total
of
four
and
a
half
hours.
We
have
nine
half-hour
slots,
we've
actually
got
ten
talks.
I'm
expecting
a
couple
of
them
to
be
relatively
short.
Lane
will
be
among
that.
So
I
think
will
actually
be
good
for
time.
A
People
speaking
plan
on
about
half
an
hour,
and
if
you
need
less
that
is
well
well
accepted.
We
have
one
agenda,
which
is
that
john
grochowski,
the
thing
that
he's
working
on
with
the
ietf
SSID
is
likely
to
happen
in
the
imminent
future
very
quickly.
So
he
wants
to
speak
first
and
have
whatever
discussion
is
gonna.
B
A
To
get
that
out
of
the
way,
does
anybody
else
have
any
agenda
bashing
that
you
want
to
do
Geordi
right
right,
you
sent
me
the
slides
I've
got
that
on
there,
so
okay
yeah!
Well,
basically,
the
last
half-hour
probably
got
Thursday
is
going
to
be.
The
Geordi
show,
whatever
it
is,
you're
good.
So,
okay,
any,
but
anybody
have
anything
else.
C
A
Tell
you
I
can
do
that.
Okay,
but
with
that
I'm
gonna
consider
the
agenda
so
now.
Actually
no!
This
is
John.
Where
are
you
yeah?
So
here's
the
mic,
Oh
speakers-
this
has
been
true.
The
last
couple
of
IETF
you're
supposed
to
stand
inside
this
little
tiny
box
and
you
know,
stand
on
this
postage
stamp
here
plays.
D
E
Ready,
okay,
okay,
good
morning,
everyone
John
verzasca
here
so
I'll
represent
the
other
folks.
The
multitude
of
authors
on
the
draft
that
Fred
up
had
Peter.
So
basically
the
gist
there
there
are
no
additional
slides.
Fred
was
generous
enough
to
open
up
a
web
page
to
be.
You
know
the
visual
aid
here
for
today,
for
those
who
have
not
read
the
giraffe's,
it's
pretty
simple:
it's
basically
eating
our
own
dog
food.
E
Possibly,
you
know
maybe
missed
that
as
part
of
the
conversation
that's
far
so
we're
not
yeah
and
I
know,
we've
had
some
conversations,
people
about
a
bad
experiment
that
may
be
rusted
a
few
years
ago,
where
we
turned
off
before
entirely
with
you
know,
no
help,
ie,
no
nat64
that
that's
not
what's
being
proposed
here.
I
mean
as
much
as
I'd
love
to
see
that
happen.
E
You
know
someday,
perhaps
yeah
in
my
lifetime
or
career,
or
what
have
you
I
think
it'll
be
a
while,
maybe
depending
on
connect
time
environment
you
have,
but
but
but
at
this
stage
of
the
game
we
still
need
some
some
help
for
before.
So
the
proposal
that
we
put
together
is
an
incremental
approach
to
a
Medusa
only
to
the
main
SSID
right.
So
myself,
Jim
Randi
yari
when
he
was
the
ITF
chair,
ELISA
now,
I
think
we've
been
having
this
conversation
since
at
least
Sol
Jim,
yeah.
F
E
Doc
had
been
very
generous
patient,
tolerant,
I
guess,
maybe
in
a
better
word,
we've
made
some
preparations
from
you
know
we
get
up.
We've
done
our
best
to
help
me
some
preparations
from
a
hardware
point
of
view
to
make
sure
that
we
have
production
grade
equipment
that
that
is.
You
know
that
we
can
stand
behind
as
far
as
you
know,
offering
a
reliable,
v6,
only
environment
that
has
nat64
and
dns64.
So
so
the
crux
that
this
is
this
right:
if
you
look
at
this
this
page
here
and
Fred,
would
you
mind
enough?
E
You
don't
have
to
do
anything?
It's
fun.
There
are
43
devices
connected
to
the
net
6-4
environment
here
at
the
ITF
there's
more
than
43
people
here,
there's
PI
more
than
40
people
in
this
room
not
heavily
utilized,
and
if
memory
serves
me
Jim
will
keep
me
honest.
I
think
that
number
was
12
in
Chicago,
ish,
Jim,
yeah
yeah.
E
G
E
E
Five:
nine
ten
million
50
million
right
now.
Okay,
so
and
I
said
me,
six
only
gray,
so
I've
lots
of
devices
that
are
that
every
sink
only
I'm,
not
talking
about
the
dual
style,
I've
excluded,
two
brought
the
de
braga
device
that
are
dual
stack
in
when
I
raise
my
hand.
So
so
what's
the
deal
right,
so
it's
good
enough
for
it's
good
enough
for
us
at
work,
but
not
good
enough
for
15
hire
people
at
the
ITF
I.
Don't
think
so
that
break
fly.
D
E
Not
good
enough
yeah,
it
doesn't
fly
right.
So
with
that
being
said,
that
is
the
proposal.
The
proposal
is
basically
to
organize
a
kind
of
trial.
So
to
speak
of
this,
this
is
not
an
experiment.
Right
so
I
mean
I'm
the
perfect
honest
with
him.
You
know
as
much
as
I'd
love
to
experimental
things
that
the
intention
here
is
not
to
for
this
to
be
an
experiment.
E
E
A
E
Fred
bad
friend,
you
can
put
a
friend
attention.
You
gets
demerit,
so
you
know
I
Love,
You
Man,
so
so
that's
the
proposal
is
to
make
that
SSID,
Biden
v6
only
would
not
1606
for
right.
So
there's
no
there's
been
a
very
lively
discussion.
You
know,
and
you
know,
there's
been
a
kind
of
wide
range
of
opinions
which
we
appreciate
respect
but
but
either
way,
yeah
I
think.
The
idea
here
is
that
we
we'd
like
to
move
this
forward
and
we
need
some
and-
and
we
latest
discussed
this
with
the
Ari
Neeman
ELISA.
E
G
G
Don't
think
the
current
state
of
situation
in
any
way
negatively
impacts,
ipv6
I.
Simply
think
that
if
you
happen
to
be
on
ITF,
you
can
use
either
v4
or
v6.
You
can
maintain
an
end-to-end
model
with
no
middleware
boxes
in
the
middle
and
provide
full
connectivity
in
fact
actively
breaking
what
you're.
What
we're
referring
to
as
the
default
SSID
by
putting
something
in
the
middle
that
could
potentially
introduce
problems,
seems
counter
to
the
goal
of
ensuring
that
the
primary
network
here
allows
people
to
get
the
work
done,
that
they
need
to
get
done.
G
I,
with
the
other
options
being
available,
I
think
that
anybody
who
wants
to
use
it
it's
there,
but
forcing
people,
particularly
people
who
are
not
be
six
people
I
mean
there
are
a
lot
of
people
that
come
to
the
IETF.
The
barre
focus
is
entirely
elsewhere.
Is
that
they
don't.
This
isn't
something
they're
focused
on
trying
to
do
so.
Why
make
them.
E
If
I'm
an
genuine
one
second,
so
I
well
I
do
respect
their
opinion.
I
I
do
hundred
percent
agree
and
you
know
that
right
I
do
not
agree
right.
You
know
with
our
experience
over
the
past
decade
or
more
one
of
the
things
that
we
find
I,
don't
call
it
breaking
it
right.
I
called
finding
bugs
right.
Just
yesterday,
Geordi
was,
you
know,
commented
about
something
that
open
OpenVPN
or
something
I
mean
with
just
a
push
on
the
email
list,
we're
finding
things
that
really
need
to
be
fixed
right.
E
H
Google,
first
of
all,
we've
just
we've
just
seen
that
some
people
get
connected
to
IT
fsociety
accidentially,
while
they
probably
really
would
like
to
be
connected
to
not
six
for
society
right,
so
I'm,
pretty
sure
we
can
get
more
users
on
this
and,
secondly,
from
experience
of
running
v6
on
the
network's,
we
get
a
tribe
actually
right
and
and
I
be
seen.
I've
been
using,
not
six
for
SSI
additions.
My
first
idea
and
initially
I,
had
to
switch
back
a
couple
of
times
but
those
but
been
fixed.
I
So
it's
just
as
easy
for
people
to
join
that
six,
for
as
it
is
for
them
to
join
the
regular
network.
However,
we
see
a
lot
of
people
are
joining
the
ITF
NIT
of
legacy.
Okay,
maybe
you
can
ignore
the
hf
legacy,
but
there
are
way
more
people
who
joined
ITF
and
ITF
2.4.
Only.
Maybe
that
proves
that
you
know
the
food
isn't
that
tasty
people
are
joining
the
ITF
one
for
a
reason.
If
they
wanted
nat64,
you
click
the
other
button.
It's.
E
Not
hard
wine,
it's
kind
of
a
lame.
You
know
you
know
position
right,
I
mean
it's.
It's
the
default
right,
yeah
when's,
the
last
time
you
clicked
on
at
one
time
10
years
ago,
when
it
was
the
only
aside
either
was
on
that
six
for
it's,
the
defining
computer
dude
right,
it's
hot!
That's!
You
know,
probably
the
main
reason
why
everybody
picks
the
idea
of
a
study
right
perhaps.
C
C
C
That
is
not
a
problem
if
you
can
fall
back
to
another
SSID,
which
is
dualistic,
but
if
we
want
to
detect
as
many
as
possible
broken
applications
and
things
to
help
the
developers
or
whatever
to
correct
them
or
at
least
to
signal
them
hey,
this
is
not
working.
You
should
do
something
I
think
it's
much
better
to
do
in
some
automated
way
and
that's
what
I
am
proposing
okay.
C
So
if
we
have
instead
of
many
times
reporting
which
require
a
lot
of
people
doing
some
additional
effort
and
I
am
sure
many
will
not
do
it's
human
nature,
because
when
something
that
is
critical
for
you
doesn't
work,
you
switch
to
the
secondary
SSID
and
you
don't
detect
any
anything
more.
That
is
broken
in
your
laptop
right.
That's
going
to
happen,
oh
I'm
not
going
to
away
which
detects
for
us.
Yes,
we
need
to
do
maybe
some
small
development
some
script,
something
that
help
us
to
automatically
detect
as
many
as
possible.
Broken
things.
C
That's
the
basic
point:
I
am
I,
am
doing
I
am
NOT,
saying
not
not
do
that.
Just
do
that
in
a
different
way
which
facilitate
the
work.
One
one
question,
maybe
for
Jim,
actually
how
many
rappers
you
are
getting
in
recent
IDF's
for
broken
things
in
the
nat64
network,
maybe
that
that
gives
an
idea
of
how
many,
how
much
people,
even
if
it's
a
small
number,
is
actually
contributing
to
that.
G
C
G
And
just
actually
to
address
that.
I
just
wanted
to
mention
it
where,
because
of
the
fact
that
we're
starting
to
get
some
issues
on
the
net
six
four
we're
collecting
and
we're
gonna
make
a
wiki
page
so
that
everybody
can
see
what
the
issues
are
that
are
outstanding
and
we'll
feed
that
back
to
a
ten
whose
hardware
we're
using
yeah.
K
E
Jory,
don't
go
anywhere
yet
so
the
two
two
things
so
so
you
have
to
believe
I
mean
so
so
we
should
talk
to
you
about
the
comments.
Are
you
making
because
it's
a
what
you're
saying
verbally
didn't
come
through
to
me
on
email
right?
That's
not
the
one
same
one
came
through.
So
let's
talk
separately
and,
let's
and
then
see
you
know
it's
kind
of
hard
for
some
of
those
ideas.
One
thing
you
also
have
to
know
about
me
right,
dude,
I,
don't
really
big
write
in
an
address
right.
E
It's
kind
of
pain
in
the
ass
right.
I
didn't
write
this
because
I
really
wanted
to
write.
I
wrote
it
because
when
we
sat
down
with
Jim
and
the
rest
of
the
knot,
guys
are
like
hey,
can
you
can?
Can
we
get
some
documentation
together
to
kind
of
at
least
jumpstart
this
process
right?
If
I
could
have
skipped
it,
dude
I
would
have
man.
I
would
I
would
hand
off
some
PowerPoint
say
hey,
let's
do
this
right,
so
I
mean
you
know.
E
E
So
I
sort
of
disagree
with
you,
Jim
I,
think
so
so
this
this
deployment
bottle
is
the
future
right
is.
It
is
the
only
sustainable
v6,
only
development
model
that
deployment
model
that
I've
seen
so
far,
because
the
dual
stack
model
is
fundamentally
operationally
more
expensive.
This
is
what
this
the
internet
is.
Gonna
look
like
now.
The
only
question
is:
do
we
want
to
live
in
the
future
to
be
one?
I
live
in
the
past
one
other
than
past.
Let's
turn
off
a
toe
2.1
x.
Let's
turn
off
v6,
let's
say
v4.
E
Only
let's
go
back
to
1999
and
that's
the
ITF
network.
Lowest-Common-Denominator,
that's
safe
right,
near
their
depth.
We
know
that
there
are
devices
at
this
conference
with
v6
bugs
that
don't
support
802.
We
don't
want
X,
we
don't
support
those
on
the
main
SSID.
We
say.
If
you
have
one
of
these
insert
adjectives
here
devices,
then
the
legacy
network
is
for
you
and
I
think
we
should
do
the
same
here
at
some
point.
You
know.
Maybe
it's
not
today.
E
If
we
know
that
there
are
known
Hardware
bugs
and
our
implementation,
we
can't
actually
ship
it
as
the
default,
but
you
know
fear
of
client
breakage
when
all
we
need
to
do
is
send
an
announcement
and
say
hey.
If
you
see
a
bug
a
report,
it
be
used
one
of
these
other
ones.
That's
not
a
high
bar
for
our
users
to
jump
there.
E
G
It's
not
mine.
Personally,
there
are
a
bunch
of
us
that
are
working
on
this,
but
I
think
the
key
that
we
need
to
all
think
about
is
what
is
the
objective
of
the
network
that
we
build
here?
Is
the
objective
to
facilitate
people
being
able
to
successfully
work,
or
is
the
objective
to
put
to
support
a
specific
ideology
or
a
specific
idea
of
moving
forward
and
I?
Think
that
that's
definitely
something
we
want
to
hear
from
the
community.
G
The
view
from
from
the
NOC
is
that
we
want
to
make
sure
that
people
have
the
most
successful
use
of
the
network
period
and
we
want
to
make
sure
that
if
you
want
to
do
some
other
things,
their
capabilities
they're
built
into
the
network,
but
that
fundamentally
it's
whatever
is
gonna,
make
it
work
most
successfully.
So
I
guess
that's
really
got
to
answer
that
before
we
move
forward
yeah
two
things
before
David
goes.
E
So
the
we
here
is
the
1,200
people
who
are
here
right,
I,
think
I
I
agree
with
you.
Ray
like
this
is
not
Jim
so
like,
let's
not
like
reverse,
throw
through
to
Jim
right
cuz.
This
isn't
Jim.
This
is
a
community
decision
that
we
all
need
to
make
right
and
I'll
get
to
that
towards
the
end
of
the
kind
of
the
talk
here
and
and
to
Kumiko
uncommon
to
the
something
you
just
said.
E
When
we
were
kind
of
having
the
email
changes
as
we
write
in
the
draft
was,
it
was
actually
a
very
useful
proposal
to
have
like
IETF
insert
number
here,
fallback
SSID
every
time
you
know
the
basically
makes
that
people
had
to
deliberately
pick
the
new
number
SSID
right,
so
I
built
that
in,
like
you
know
and
and
we're
sensitive,
that
every
single
one
of
us
who's
written
in
the
document
have
production
experience
to
point
to
very
large
population.
Cuz
it's
so
we
know
what
it
takes
to
not
piss
two
customers
off
and
not
get
fired.
G
Just
one
more
point
on
the
you
that
mentioned
know:
everybody
is
on
an
IETF
because
they
have
it
in
their
in
their
cash
from
a
long
time
ago
the
ietf
legacy.
Ninety
nine
was
an
interesting
experiment
for
us
to
see
if
people
actually
really
wanted
to
be
on
the
legacy
network
and
clearly
a
lot
of
people
did
because
they
had
to
choose
so
I'm,
not
sure
if
we
truly
have
people
that
are
on
these,
just
because
it's
cash,
true
interesting.
D
C
L
Ganassi
Apple
I
wanted
to
add
a
point
on
birdies
comment
about
automating
issue.
Detection
I
totally
agree
if
we
had
a
way
to
do
that,
that
would
be
obviously
better
asking
people
to
report
failures
as
a
pain,
no
argument
there.
However,
it's
something
we
tried
to
do
for
a
long
time
this
year.
Actually
last
year
now,
we
deployed
v6
only
for
some
iPhones
without
464xlat.
L
So,
on
a
network
like
this,
even
though
it's
not
ideal
asking
people
or
having
them
join,
this
network
is
a
great
way
to
see
what's
broken.
In
your
case,
your
Open
VPN
config
file
was
wrong,
being
able
to
figure
out
from
some
of
the
logs
and
some
of
the
boxes
on
the
network
that
that
was
the
case
is
just
completely
impossible,
and
now
it
was
an
experiment
that
took
five
minutes
and
you
fixed
your
config
file,
and
you
were
one
step
further
to
having
software
that
works.
What.
C
I
am
suggesting
is
not
actually
detecting.
What
is
the
failure,
because,
obviously,
in
this
case,
in
the
open
VP
an
example,
it
goes
some
people
that
help
it,
but,
for
example,
I
detected
also
Microsoft
Office
in
Apple
having
the
same
problem,
but
I
try
to
investigate
it
and
I,
don't
have
the
source
code
or
whatever
to
try
to
find
it.
So
I
am
not
telling.
Let's
do
that.
I
am
telling
just
to
dump
some
packets
for
every
seal
at
communication,
which
means
that
those
applications
that
are
making
those
packages
flows
are.
C
L
L
C
I
really
wish
that
everybody
has
the
capability
to
go
to
the
next
64
and
actually
report
every
broken
thing.
But
my
experience
because
many
people
here
needs
the
network
to
keep
working.
We
know
it.
So
my
experience
is
that
when
you
are
in
that
situation
you
switch
to
the
legacy
or
whatever
SSID.
That's
that's
my
experience
totally
I
needed
to
do
and
that's
that's.
A
L
M
Michael
Richardson
I'm,
very
supportive
on
I,
want
to
point
out
that
the
number
went
from
43
to
61
lawyer
talking
so
and
I
did
push
the
buttons
to
and
there
you
go
so
I
I'm
supportive
of
moving
to
this
and
I
think
we
should
have
a
plan
and
I'm.
Sorry
I,
didn't
read
you
the
draft
but
and
I
know
there
was
plans
of
doing
it.
Some
incrementally
so
my
question
actually
for
Jim
is
what
what
amount
of
effort
would
it
take
to
selectively
turn
off
the
ietf
network
in
certain
working
group
sessions
like
this
one?
M
G
G
They
and
they
and
they
bleed
between,
but
we
could
work
something
like
that
out.
Actually
one
of
the
key
things
I
want
to
want
to
mention
is
that
we
aren't
opposed
in
general
to
doing
changes.
That's
certainly
not
the
case.
We
just
want
to
make
sure
that
whatever
changes
we
do
make
are
planned
and
actually
have
a
rollout
schedule
so
that
we
do
so
that
we
can
do
things
in
a
sane
way.
Once
we've
agreed,
where
we're
going
well.
M
M
Maybe
IGF
nat64
is
the
only
one
that
doesn't
change
and,
and
that's
my
thought
so
incrementally
try
and
grow
that
Samedi
I
think
and
maybe
when
it's
at
two
or
three
hundred
that
maybe
it's
time
to
yeah
than
to
think
about
it,
and
and
maybe
that's
only
three
I
tf's
from
now
or
something
like
that.
There.
G
Eliminate
true
rename
it
from
IETF
to
IETF,
dual-stack
or
something
along
those
lines,
and
there
won't
be
an
IETF
SSID
you'll
choose
one
of
the
others.
It
happens
to
be
net
60
or
happens
to
be
tools
that
you
made
a
choice.
Okay,
that
doesn't
that
would
have
the
effect
of
making
everyone
make
a
choice
and
then
and
then
they
can
be
where
they
want
to
be.
That's,
but
that's
a
proposal.
That's
on
the
table
were
playing
around
with
it.
I
like
it.
H
Jenny,
first
of
all,
EGF
legacy
just
proves
that
if
something
does
not
work
for
you
on
default,
SSID
people
fall
into
analysis
idea
and
their
Scalia
did
not
follow
right.
So
I
think
it
looks
like
it's
feasible
for
people
to
switch
society.
If
the
equipment
I
personally
volunteered
to
help
people
with
changing
SSID
on
their
laptops,
if
they
need
help
and
second
point,
do
we
have
okay?
We
are
saying
that
we
are
probably
not
ready.
All
those
devices
could
not
join
v6
on
SSID.
What
would
be
the
criteria
when
we
believe
we
are
a
dia?
I
I
If,
when
we
ask
people
before,
what's
your
purpose
for
the
network,
a
large
amount
of
them
said
I
just
want
to
get
stuff
done,
so
we
shouldn't
take
the
views
only
within
this
room
as
being
representative,
the
whole
community,
if
we
were
you
know,
would
be
a
fairly
clear
choice.
Check,
making
the
changes
trivial
to
do
right.
It's
just
is
that
what
the
community
itself
wants,
or
is
that
what
this
group
of
the
did?
You
say
the
IAB.
I
N
But
I
mean
you're
asking
a
question
right:
okay,
Jolie
eglee,
when
I
make
a
decision
as
a
business
like
I'm
doing
that
on
behalf
of
my
customers
and
my
business
intentions
right
you're,
not
doing
that
for
this
enterprise,
I,
don't
get
it
yeah!
Well,
you
don't
have
to
I
kind
of
do
no
like
yeah
when
when
we
go
out
and
we
make
commercial
decisions,
we.
F
F
A
E
So
final
comments,
so
the
ask
of
you
guys
give
this
a
try.
You
know
please
join
us,
we're
having
some
discussions
with
Jim
and
others
at
the
ITF
to
decide
what
to
do
for
basically
the
rest
of
this
ICF
meeting
as
a
community,
so
you
know
give
it
a
go.
Read
a
draft.
Send
email
on
the
list
today
would
be
good.
If
you
don't
mind.
Thank
you.
Okay,.
O
O
O
So,
as
might
be
expected,
it's
a
fairly
large
network.
The
main
campus
in
Redmond,
which
is
just
outside
Seattle
and
in
the
USA,
is
over
a
hundred
buildings,
and
the
network
generally
is
organized
instead
of
the
into
three
regions
outside
of
that,
as
most
enterprises
are
with
Europe,
North,
America
and
Asia.
So
one
thing
you'll
notice
here
is
that
the
the
number
of
on
premise
data
centers
has
been,
has
dropped
dramatically
and
from
reven
down
to
four.
O
So
clearly,
the
implication
of
that
is
that
a
lot
of
the
internal
properties
have
moved
from
those
data
centers
out
into
into
the
cloud,
so
that
I
mean
that
makes
a
statement.
It
also
means
that
some
of
our
traffic
patterns
have
changed
and
it
makes
you
know
it
gives
us
some
new
challenges.
Most
of
the
tail
side.
O
Why
so
I
I
think
within
within
our
own
sort
of
environment?
Here
it
seems
to
be
axiomatic
that
ipv6
only
is
a
better
thing.
O
Not
only
have
we
exhausted
1918
space
that
we
have
some
overlaps,
so
that
sort
of
leads
to
some
unpleasant
but
necessary,
some
net
solutions
which
are
complicated
but
I,
think
going
back
to
a
point
that
I
think
Lorenzo
made
earlier
on.
This
is
the
compelling
thing
for
us.
The
long
term
view
has
got
to
be
getting
rid
of
dual
stack:
dual
stack
is
hard
and
it's
it's
very
complicated
and
it's
very
expensive
for
many
reasons,
I
mean
the
obvious
ones.
O
Are
you
know
you've
got
to
maintain
two
IGP
easy,
but
to
maintain
you
know
two
sets
of
ICL's
two
sets
of
firewall
policies,
etc,
but
the
last
one
there
is
is
it's
a
sort
of
a
hidden
cost
and
but
it's
very
real
and
that's
the
the
support
element
of
it.
Supporting
two
two
protocols
is
very
difficult
and
sort
of
there's
a
server,
a
reflexive
move
to
sort
of
the
disabled
body
v6.
If
there
are
problems,
and
unfortunately
that
fixes
things,
but
it's
not
that's
not
the
long-term
solution.
O
O
O
So
it's
opt-in
at
this
point,
but
we
have
plans
to
chip
to
make
it
sort
of
the
default
access
method.
We
have
some
tests,
a
segments
in
Europe,
North
America
and
an
Redman
campus
for
supporting
the
product
groups
and
they're
working
pretty
well,
so
our
existing
plans
are
to
expand
their
offering
to
again
more
product
groups
and
and
and
more
reach
in
this
Asia
in
particular.
Again,
you
know
because
I
think
is
there's
a
lot.
O
We
can
learn
from
that
and
then
we
will
be
polishing
jewel
stack
and
said
why
I
could
be
six
only
and
I
think
just
I
think
this
is
probably
good.
You
know
I
hadn't
really
thought
about
this
bit
of
it,
but
I
think
it's
worth
me
make
you
know,
making
a
couple
of
statements
here,
I
think
from
the
previous
discussion,
I
speaking
personally,
as
a
network
operator,
I
think
it
from
the
last
discussion.
I
think
it
is
important
to
to
try
push
ahead
with
with
v6
only
because,
if
there
is
a
fallback,
I
mean
that.
O
If
users
discover
issues
and
they
report
them
back
and
I,
think
they
were
one
step
closer
to
to
finding
out
what
you
know
how
to
do
this
in
a
large-scale
plane.
That's
just
my
opinion.
So
so
you
know
in
some
way
you
know
I
would
support.
You
know
with
the
with
fall
back,
we've
been
working
towards
v6.
Only
anything
slowing
us
down,
I,
think
guest
network
deployment.
O
So
this
is
an
interesting
wide
problem.
A
colleague
of
ours,
Todd
Thornton,
spoke
at
the
Facebook
conference
recently
and
only
to
the
attendees
could
actually
connect
their
VPN
over
the
v6
only
network.
So
that's
that's.
That's
a
problem.
There's
no
doubt
about
it,
but
you
know
I,
think
you
know,
but
it
what
did?
What
has
it
done?
Is
it
engendered
a
lot
of
research
and
a
lot
of
you
know
a
lot
of
people
looking
into
this,
so
I
think
that's
that's
where
we're
going!
That's
what
we're
doing
currently
no
platform
features.
O
This
has
been
covered
in
quite
again.
Quite
a
few
forms
and
our
DNS
s
on
on
the
ratios
is,
is
one
with
work.
We're
currently
dealing
with
and
wireless
controller
security
features,
so
I
mean
this
is
like
I
said
this
being
covered
and
having
to
talk
about
this,
you
know
later
on
or
over
over
beer
or
whatever
so
new
building
configuration.
This
is
kind
of
an
interesting
one
for
us
in
olden
days.
You
know
the
segments
were
much
more
homogeneous
in
that
you
might
have
say
finance
or
HR
on
a
single
segment.
O
It
was
much
easier
to
determine
sort
of
what
sort
of
applications
might
be
running
on
that
segment
and
therefore,
what
what
you're
likely
to
break
if
you,
if
you
move
it
to
two
v6
only
along
with
other
sort
of
enterprises,
we
now
this
new
world
of
work
as
they
call
it.
Where
you
have
much
more
heterogeneous
segments
for
you
again,
you
might
have
engineering
and
finance
and
HR
all
in
the
same
segment,
so
it
makes
it
much
more
difficult
to
determine
what
is
actually
running
on
this.
O
This
is
sort
of
I
mean
this
exists
in
you
know,
in
at
a
larger
level,
but
also
really
for
us.
The
big
problem
here
is
going
to
be
mostly
a
tail
size,
and
so
this
will
leads
onto
one
of
one
of
our
sort
of
corporate
strategies,
which
is
internet
first
and,
as
the
name
describes,
it's
basically
having
locally
egress
at
a
branch
office,
and
there
are
many
reasons
for
that.
O
You
know
amongst
them,
cost
performance
and
obviously
it
implies
sort
of
when
you
do
get
a
local
egress
that
you
have
some
address
base
from
the
ISP.
So
it
brings
up
the
question
now
that
you
have
potentially
tubes
prefixes
sitting
on
the
segment.
You
know,
how
does
how
does
that
work
from
from
a
routing
point
of
view?
It's
it's
in
theory.
Quite
you
know
straightforward.
If
you
can,
you
can
use
such
techniques
as
so
the
policy
based
routing
which
operationally
is
very
difficult
and
I
know.
O
Obviously,
there's
it's
been
around
for
a
long
time,
but
you
know
it's
one
of
these
things
that
will
sensitive
rock
in
the
mornings,
and
sometimes
it
doesn't
so
a
source
addressed
defendant
roofing.
Is
that
there's
a
lot
of
work
going
on
moment,
I'm
looking
into
this,
and
this
becomes
interesting
because
it's
certainly
much
much
much
better,
because
it
gives
you
a
lot
more
flexibility
but
further.
O
Furthermore,
if
you
know
if
it's
in
the
ribbon
in
the
fitbit's,
it's
operationally
much
more
supportable,
but
it's
just
there's
still
the
issue
of
the
source
selection
with
multiple
prefixes
on
the
segment
and,
obviously
the
source
selection.
You
know
67
24,
it
will
produce
a
result.
That
is
correct,
but
it
may
not
be
the
result
that
you
want.
O
So
this
is
coming
really
an
example.
What
I'm?
What
I'm
talking
about-
and
it's
this
this
is
fairly
real.
So
you
would
you
have
to
hear
a
typical
scenario
here
where
you
have
a
researcher,
a
branch
office
researcher,
and
it's
been
addressed
out
of
the
under
the
corporate
/
32,
and
you
know
it
has
local
internet
egress
from
the
ISP
and
it's
being
assigned
out
of
48
out
of
that.
So
if
it
wants
to
connect
to
a
device
in
in
corporate
network
which
is
address
out
of
a
different
32,
then
what
you
know.
O
So
what
is
it
going
to
do
so?
In
this
case,
you
can
do
to
long
as
much
what
it
will
do
is
will
it
will
use
the
ISPs
/
464
in
this
case,
to
connect
to
the
corporate
network
in
North
America?
Equally,
if
the
host
wants
to
get
something
in
adder,
if
it
will
use
I
mean
closest
because
the
Yahoo
32
is
adjacent
to
the
to
the
corporate
32,
so
it
will
use
that
as
a
source.
So
it's
correct,
but
it's
but
it's,
but
it's
not
really
not
what
we
want.
O
So
really
there
a
couple
of
options.
I
think
that
we
could
you
know
we
could
use
this
or
overcome
this
I'm
sort
of
a
numerating
this
just
because
it
actually
is.
You
know
it
is
a
sort
of
an
option
and
not
with
NAT
six
six.
It
may
be
just
a
sport,
but
it
actually
would
overcome
the
issue
there's
a
possibility
of
using
the
ISP
space
exclusively,
in
which
case
you
know.
O
O
It
looks
as
if
there
is
a
direct
connection
with
the
ISP
and
and
with
corporate
network,
and
in
some
cases
there
is
that,
but
in
other
cases
a
lot
of
cases
as
I
mentioned
earlier
on,
but
the
tails
that
connectivity
is
through
a
layer,
3
VPN
and
what
that
would
mean
is
we'd,
have
a
private
is
Genie
BGP
with
the
carrier,
and
then
we
would
ride
as
a
left
free
VPN
back
to
the
hub
site.
So
if
you
had
an
intention
egress
there,
you
wouldn't
you
would
have
to
do
peering.
O
O
Can
you
so
I
think
I
know
you
know
with
I
should
have
put
this
as
a
larger
point
in
the
bullet,
but
I
think
you
know
it
feels
a
bit
of
the
you
know
from
a
prone
operate,
one
of
you
using
the
your
own
eye
space
and
the
ISP
space
seems
like
the
right
thing.
If
you
could
get
it
to
do
what
you
want.
O
So
that
is,
that
needs
a
potential
but
I
think
also-
and
this
is
important
stuff
described
in
Joan's
graph
there,
on
conditional
Ras,
I-
think
on
really
the
interaction
between
survey
and
EEMA,
the
researchers
and
on
the
RHIB
I
think
that
this
is
inevitable.
I
mean
whatever
we
do
this.
This
is
gonna
have
to
happen.
I
think
you
know
I
think
it's
analogous
to
tracking
in
using
other
technologies,
but
I
think
this
is
gonna,
be
important,
but
I
think
I
mean
well
well,
you
can
get
things
to
work
here.
I
think
you
know
it's.
O
It's
really
limited
in
a
certain
way,
particularly
if
you
have
say
remote,
water,
brushes
advertising.
You
know
egress
from
multiple
points
that
becomes
a
little
bit
a
little
bit
trickier,
so
I
think
the
more
sophisticated
solution
is
required
and
provisioning
demands
fit
that
bill
in,
in
my
view,
so
provision
provisioning
domains
apologize
in
advance.
So
if
any
of
your
within
in
six-man
yesterday
Pierre
I
presented
the
this
in
talking
by
PV
DS,
but
I
think
it's
I
think
it's
important
so
I
sort
of
cover
it
again,
I.
O
O
O
So
this
is
a
sort
of
an
illustration
of
how
this
might
you
know,
fix
the
problem
that
we
have
from
from
earlier
again,
we
had
this
at
the
same
situation.
They
are
the
same,
48
is
being
announced,
but
you
also
have
to
to
Ras
and
in
this
case-
or
we
can
signal
in
ra0
that,
if
you're
going
to
the
corporate
network
in
north
america
that
you
need
to
use
at
the
saj
64
from
the
corporate
space,
so
that
means
we
can
keep
the
corporate
routing
tables
nice
and
clean.
O
Equally,
if
we're
aggressing
to
a
larger
property
on
to
the
ISP
link,
we
can.
We
would
use
that
this
will
be.
The
prefixes
is
assigned
in
our
a1
so
and
then,
therefore
we
can
sort
of
clean
it
clean.
If
you
know
divide
the
traffic
up
like
that,
so
I
think
that's
nothing.
That's
pretty
pretty
elegant,
so
I
think
the
in
conclusion,
since
you
know
some
final
thoughts,
I
think
Jill
stock
is
hard
and
I
think
a
hard
and
expensive,
so
I
think
moving
moving
towards
v6.
Only
I
think
is
it's.
You
know
it's,
it
is.
O
It
is
obviously
the
long
term
goal
but
I
think
even
it
I
mean
I've
thought
about
this.
A
bit
I.
Think
even
new
segments
I
mean
for
for
companies,
I
mean
what
you
could
you
can
go
either
to
deploy
a
dual
stack
or
you
can't
apply
deployed.
These
takes
only
I.
Think
if
you,
if
you
plan
from
the
ad
set
for
new
segments
for
v6
only
with
with
the
dns64
nat64
solution,
I
think
that's
I,
think
that's
probably
an
easier
and
better
long-term
bet.
O
We
still
need
to
solve
this
sort
of
multiple
prefix
issue
and
I.
Think
that
that's
not
going
to
go
away
and
I
think,
although
I
think
there
are
a
lot
of
companies
looking
into
the
idea
of
local
egress
and
if
that's
not
the
only
environment,
where
you're
likely
to
have
multiple
prefixes
on
the
same
segment,
so
making
an
intelligence
or
having
the
client
make
an
intelligent
decision
about
what
sauce
to
use
will
be
important
and
I
think
you
know,
as
I
say,
it'll
give
you
a
lot
more
flexibility
and
there's
a
potential
for
for
innovation.
O
There
I'll
just
finally
concluded
by
sort
of
pointing
this
at
some
great
ipv6
stack
updates
for
Windows
10
greatest
edition.
This
was
sort
of
blog
entry
there,
so
I'd
encourage
you
to
go.
Read
that
so.
That's
all
I
have
so
I'm
happy
to
take
any
questions
either
here
or
outside,
as
I
offer
a
beer
or
coffee
whatever.
N
O
For
provisioning
domains,
this
is
really
from
on
lighty
point
of
view,
so
I
would
I
wouldn't
be
able
to
speak
on
behalf
of
the
product
groups.
Do
you
know
if
information
about
pvd's
can
be
routed
to
the
right
people?
I
could
certainly
have
that
discussion.
But
I
say
this.
This
is
if
we
went
with
looking
at
these
problems
independently,
so.
P
E
Lorenza
Collini,
can
you
go
back
one
your
line,
Remy
this
one
I
love
this
slide,
I,
absolutely
love
this
slide.
This
is
what
we
should
be
doing
and
I.
You
know
major
major
props
to
you
to
showing
up
and
and
pointing
your
way
here.
I
think
this
is
super
useful
and
it
really.
It
really
explains
what
we
need
to
do:
I
think
to
do
multihoming
without
scalability
issues,
without
that
it's
great
and
I
think
it's
a
major.
E
Actually,
it
is
a
major
driver
as
well
for
the
PVD
work
that
we're
seeing
happen
outside
myth,
but
you
know
also
actually
happening
right
now.
So
I
guess
one
question
is
like:
what
can
anyone
do
to
help
this
I
mean
we
can
go
off
and
build
it?
Maybe,
but
what
what?
What
else
is
so
suppose
that
we
did
have
PVD
just
along
the
lines
of
what
you
know,
Tommy's
drop
was
what
what
else
is
missing:
I,
don't
I,
never
liked
5.5.
It
seemed
like
a
hack
that
seems
better
what.
E
O
P
So
I'm
just
gonna
answer
one
of
the
variations
of
one
of
your
questions,
which
is
what
could
we
do
to
make
better
progress
and
things
I
said
the
the
request
for
PV,
DS
and
stuff
have
been
Robert
to
the
right
people.
I
think
what
you
guys
could
possibly
do
is,
if
you
have
an
enterprise
network
that
is
running
into
the
same
problem.
Send
me
email
and
say:
I
have
an
enterprise
network
I'm
running
into
the
same
problem,
because
the
bore
such
emails
that
I
have
to
use
your.
P
H
General
enterprise
network
suffering
from
sub
problem.
One
minor
comment.
First
of
all,
you
must
be
really
didn't
like
it
if
you
can
use
longest
prefix
match
anyway,
because
you
must
have
just
one
v6
prefix
for
this
to
work
right
and
one
question:
can
you
share
your
experience
in
terms
of
what
percentage
of
you
users
had
to
fall
back
to
dual
stack
after
you
connected
them
to
v6?
Only
what
what
was
you
experience
did.
Your
support
line
was
the
male
team
because
nothing
worked
or
it
was
like
some
reasonable
experience.
O
O
And
I
think
this
is
that's
the
sort
of
germane
question
I
think
where
we
have
enabled
this
externally
is
for
support
product
groups
and
on
ourselves
within
IT,
so
I
think
because
you
know
just
referring
to
the
conversation
earlier
on.
I
think
technology
people
are
sort
of
more
inclined
to
sort
of
work
with
that.
So
and
you
know
probably
a
lot
of
this,
the
issues
have
been
solved
by
the
PI
themselves.
Rather
than
that,
wasn't
them
being
infrastructure
issues
so
I
think
so
we
haven't,
we
haven't
seen
any
any
any
large.
Q
Ten
shown
so
as
one
of
the
co-authors
of
the
node
requirements
update,
we
were
going
to
put
in
there
what's
currently
going
to
go
in
there
about
adding
a
recommendation
to
support
five
point.
Five
in
hosts.
Do
you
now
think
that's
a
good
or
a
bad
thing
to
do
is
I
mean
Lorenzo
said
it's
a
hack?
Is
it
better
that
I
don't
think
we're
in
a
position
yet
to
put
any
words
in
that
bang
on
this
it's
too
early,
but
putting.
O
Q
Q
F
Q
O
F
H
Q
P
P
That
said,
they're
still
possibly
some
value
in
saying
something
about
five
point:
five
for
the
case
of
routers
or
provisioners
that
don't
yet
communicate
that
information.
Even
if
you
had
that
RFC
right,
because
this
is
something
an
existing
host
can
do
with
existing
information
are
getting
from
the
network
and
it
provides
a
better
answer
and
it's
not
as
good
as
what
it
could
be.
But
if
so
it's
well
five
point:
five
becomes
useless
once
there's
no
longer
any
networks
in
the
world
that
don't
provide
PVD
information,
I
just.
H
O
O
I
mean
it's
difficult,
I
mean
you
can
do
some
scenarios
with
5.5
and
as
long
as
you
have
you
know,
ar-ar-ar
iOS
in
the
are
IRAs
and
you
can
respond
to
that.
Then
you
can,
you
know,
dictate
there's
one
one,
one
RA
one
again.
Obviously
one
source
is,
you
can
reach
these
prefixes
and
then
the
others
can
be
further
can
be
used
as
a
default
route
and
then
use
that
source.
I
guess
so.
That's
I,
guess
that's
an
implicit
PVD,
but
I
guess
it
still
requires
five
point.
A
N
A
J
Don't,
oh
that's
long,
so
my
name
is
Robin
watch
way
and
Minich
Germany
and
today
I'm
going
to
talk
about
a
longitudinal
view
of
tools
like
websites,
fairly
failures,
latency
and
happy
eyeballs.
So
this
is
joint
work
with
my
PhD
advisor
you
don't
should
welder
from
University
brain
in
Germany
and
stephy
and
Sam
from
Sam
knows
who
are
paints
in
London
okay.
J
So
if
you
look
at
the
literature,
academic
literature,
you
will
see
that
large
body
of
work
has
been
done
on
measuring
v6
adoption,
but
there
has
been
very
little
work
on
measuring
v6
performance,
and
so
this
study
actually
closes
the
gap.
And
if
you,
if
you
look
at
the
law
at
the
top,
you
will
see
that
we
have
been
measuring
performance,
both
failures
and
performance
of
dual-stack
websites
since
2013.
J
J
So
we
utilize
these
Sam
knows
fruits.
Sam
knows
it.
You
know
it's
a
company
based
in
London,
which
is
giving
out
these
people
Inc
routers
to
people
for
doing
broadband
measurements,
and
so
we
utilize
this
platform.
So
we
we
had
these
probes
and
we
give
out
to
people
who
get
I
made
a
v4
and
v6
connectivity
at
home,
and
so
these
this
is
so.
The
map
is
actually
showing
you
the
deployment
of
these
probes.
J
We
have
around
100,
Sandoz
probes
deployed
all
over
the
globe
and
it's
covering
around
66
different
origin
areas,
and
there
are
some
people
who
are
actually
sitting
in
the
room
who
are
hosting
this
probe
for
me.
So
thank
thanks
a
bunch
for
hosting
this
probe
for
multiple
years,
and
you
might
also
see
that
most
of
these
probes
are
deployed
in
residential
settings,
so
the
measurement
is
actually
largely
being
done
from
home
networks.
So
why
why
home
networks?
So
that
takes
me
to
the
top
of
the
plot.
J
So
if
you
look
at
the
top
of
the
plot
on
the
left,
you
will
see
the
v6
adoption
trend
over
weekends
versus
weekdays
and
what
you
see
is,
and
so
this
is
weekends
weekdays.
And
so,
if
you
see
anything
on
the
positive
scale
on
the
v6
adoption,
you
will
see
that
there
is
more
v6
seen
by
Google
over
weekends
than
over.
J
We
guess-
and
this
is
largely
because
there
is
more
v6
deployed
in
home
networks
than
in
enterprise
networks,
and
what
you
see
over
the
time
line
is
that
this
drift
is
actually
starting
to
increase
over
the
years.
So
starting
2013.
We
started
to
see
this
drift
happening
and
this
drift
is
constantly
increasing,
which
is
also
worries
them,
because
enterprise
network
seems
to
seems
to
be
falling
behind,
and
so
that's
another
way
of
looking
at
this.
J
And
if
you
look
at
the
bottom
of
the
top
lot,
you
will
also
see
that
that
option
of
Teredo
and
six
to
four
relays
has
also
gone
down
or
weakens
so
this
seems
like
people
used
to
use
these
relays
for
getting
on
to
v6
before
2013,
and
given
that
v6
deployment
start
getting
on
track
at
home,
people
start
using
native
v6
at
home.
So
that's
the
whole
point
of
top
lot.
J
So
if
clients
are
behind
these
public
was
always
they
will
not
receive
v6
connectivity
from
Google
and,
and
so
the
pie
chart
is
actually
showing
you,
the
distribution
of
those
prefixes.
As
seen
recently
in
2017
and
shows
where
these
public
is
always
are
located,
so
they
are
largely
located
in
Japan,
Peru,
Malaysia
and
Brazil,
and
so
the
the
probe
that
I
was
talking
was
actually
deployed
in
Japan
and
US
embassies
connectivity
due
to
this
blacklist.
But
that's
a
side
story
just
thought
to
mention
this.
J
If
you
look
at
the
time
series
on
your
right,
this
will
show
you
the
adoption
of
so
how
many,
how
many
websites
in
Alexa
1
million,
have
quality
increase
in
DNS
and
how
this
has
evolved
over
the
years.
So
this
data
set
is
actually
coming
from
dan
wing
and
I'm
just
plotting
that
data
set,
and
so
what
you
see
on
the
top
of
the
timeline
is
that
there
is
a
pent
in
the
curve.
Both
that
happen
during
the
world
v60
and
world
v6
monster.
J
So
that
goes
to
show
that
CDN
can
play
a
leading
role
and
not
only
pushing
any
new
technology,
and
that
also
happens
with
Google
quick
but
also
shifting
significant
traffic
overnight
over
v6.
So
that's
my
takeaway
from
this
plot.
Ok,
so
what
have
we
done
with
the
San
Louis
Pro?
So
there
are
four
contributions
that
we
provide.
These
are
four
large
contributions,
and
so
we
look
at
complete
failures
of
these
dual
set
websites:
partial
failures
of
these
dual
stack
websites
and
we'll
talk
more
about
this.
J
What
do
I
mean
by
complete
and
partial
failure,
so
complete
failures?
When
you
try
to
reach
a
website,
you
don't
get
anything
partial.
Where
is
failure
is
when
you
get
some
portion
of
the
website,
and
so
this
is
relevant,
because
these
failures
tend
to
silently
exist,
because
clients
do
not
notice
them
because
they
tend
to
fall
back
to
v4,
and
this
also
makes
me
wonder
whether
websites,
which
are
partial
failure
can
be
beamed.
J
Ipv6
ready,
can
they
and-
and
the
last
last
point
is-
the
quantification
of
these
failures
is
actually
very
helpful
for
upcoming
v6
only
networks,
and
that's
also
one
of
the
pointers
in
the
new
chart
for
the
agenda,
and
that's
why
I
want
to
show
some
of
these
results.
Apart
from
failures,
we
also
look
at
performance,
but
in
performance
we
largely
look
at
latency
aspects
of
how
how
this
latency
compares
over
6
and
4
to
would
sees
websites
and
how
all
of
this
combines
together
towards
this
standard.
J
Now
I
see
six
five
five
five
and
can
we
can
we
do
something
about
it?
Can
we
make
an
update
to
it,
or
does
it
actually
need
an
update?
And
so
overall
this
is
the
first
study
which
has
which
has
been
looking
into
dual
stack
websites
for
such
a
long
doodle
time.
For
four
years,
both
failure
and
performance
aspects.
Okay,
so
let's
look
at
some
results,
so
the
first
thing
is
complete
failures.
J
So
if
you
look
at
the
not
on
the
top
left,
that's
actually
showing
you
the
same
Alexa
time
line
or
1
million
Alexa
1
million
websites
which
have
feel
to
make
HTTP
connection.
So
these
websites
are
for
a
increase
in
DNS,
but
when
you
make
HTTP
connection,
they
tend
to
fail,
and
so
you
don't
get
anything
when
you
make
a
connection
over
v6
and
what
you
see
is
that
the
failures
were
around
40%
back
in
2009
and
these
failures
in
to
have
reduced
to
3
percent
today,
3
percent,
which
is
also
a
large
number.
J
And
so
we
started
wondering
what
are
these
three
percent
websites
so
now
look
at
the
plot
at
the
bottom
and
what
you
will
see
is
the
distribution
of
the
the
these
three
percent
websites
that
tend
to
fail
today
and
where
do
they
rank
within
the
ranking
right?
So
the
plot
at
the
bottom
is
actually
showing
you
that
88%
of
these
failing
websites
have
ranks
which
are
above
100k,
and
so
it's
showing
that
most
of
the
websites
which
are
less
popular
in
the
Alexa
ranking
10,
are
failing
over
HTTP
over
v6.
J
There
are
only
1%
websites
which
rank
below
10k
and
only
6
websites
below
300,
so
largely
popular
websites
which
are
hosted
by
large
CDN
providers.
They
work
fairly
well
and
but
there
is
a
long
tail
that
still
exhibits
a
complete
failure.
We
don't
see
anything.
So
what
are
these
6
websites,
which
are
the
most
popular
and
ranked
below
300?
So
if
you
look
at
so
these
other
thing,
6
websites
and
the
plot
is
showing
you
the
time
series
of
so
blues.
V4
and
red
is
v6
and
I.
J
Don't
know
if
you
see,
but
in
each
of
the
time
series
you
will
see
a
vertical
marker
showing
when
these
websites
stopped
providing
code,
a
increase
in
DNS.
So
so,
for
instance,
Bing
Bing
was
part
of
the
world
v6
launch
day
and
at
some
point
and
late
2013,
it's
not
providing
array
entries
in
DNS.
So
the
bottom
line
here
is
matrix
any
matrix
that
that
are
being
used
for
basic
adoption
should
account
for
changes
in
v6
readiness.
J
J
Okay,
then
we
started
looking
into
given
that
we
found
about
this
bing.com
I
wanted
to
look
into
okay.
What
all
websites
participated
on
the
world
ipv6
launched
and
they
were
long
three
thousand
websites
according
to
internet
Society
website
and
the
promise
was
to
prompt
permanently
enable
production-ready
v6
on
the
internet
for
the
participating
website.
J
If
you
take
that
out
as
well,
you
will
see
that
eight
percent
of
the
rest
of
the
websites
which
have
both
a
and
Cordain
breeze
work
only
four,
but
they
tend
to
root
PCP
time
or
over
v6.
And
so,
if
you
look
at
the
plot
that
shows
you,
the
distribution
of
the
ranking
of
those
world
ipv6
launch
day
participating
websites
that
fail
over
six,
but
not
over.
J
Four
and
again,
what
you
see
is
it's
heavily
tailed,
so
only
three
percent
of
the
pyramid
sites
have
lying
rank,
then
a
less
than
10k,
while
most
of
them,
three-quarters
of
them
have
ranked
more
than
hundred
k.
So
again,
it's
in
the
long
tail
where
the
websites
are
failing.
Okay,
so
this
was
largely
about
complete
failures.
Where
you
don't
get
anything
now
we
talked
about
partial
failures,
where
you
again,
that's
where
you
get
some
content
over
v6
of
a
website,
but
not
everything.
J
So
we
looked
at
Alexa
top
100
websites
that
give
out
quad-a
entries
in
DNS,
and
we
saw
that
27
percent
of
these
websites
have
some
partial
failure,
then
fetching
content
over
v6,
and
so
what
are
these
27
websites?
So
now
look
at
the
table,
so
these
are
the
27
websites
that
have
some
partial
failure
over
v6
they
do
not
failover
before,
but
only
or
v6,
and
so
the
column
will
show
you
what
percentage
of
failure
you
see,
or
six
and
I
highlighted
some
of
the
websites
in
red
which
I
consider
popular.
J
But
this
is
just
from
my
own
vantage
point,
so
it
might
be
different
story
for
different
people
and
if
you
look
at
the
top
of
the
horizontal
line,
you
will
see
that
nine
percent
of
the
websites
have
more
than
50
percent
failure
or
v6.
So
half
of
the
content,
you
don't
get
if
you
are
sitting
in
a
v6,
only
network
with
no
translation,
yeah.
J
J
I
sock
is
actually
not
supporting
development
of
tools
where
you
can
go
to
a
site
and
into
such
some
a
URL
and
tells
you
what
fraction
of
failure
do
you
see
you
in
fetching
content
over
v6?
Ok,
we
also
did
some
root
cause
analysis
of.
Why
do
you
see
partial
failure
happening
or
for
for
these
27%
websites,
and
this
is
largely
happening,
because
some
of
the
content
is
just
not
having
coordinator
ease
in
DNS
for
the
website.
J
So
so
there
is
failure
to
DNS
resolution
for
body
increase,
and
this
is
largely
happening
for
images,
JavaScript,
JSON
and
CSS,
so
think
about
it.
If
there
is
a
website
that
fails
to
load
the
CSS
over
v6,
only
with
our
translation,
how
would
it
look
on
a
v6
only
network,
without
translation
and
so
and
so
again
so
failures?
J
These
failures
tend
to
silently
exist
because
clients
do
not
notice
them
because
the
v4
fall
back
and
again
so
identification
of
these
operational
Network
issues
are
irrelevant
for
upcoming
v6
only
Network,
because
at
some
point
in
time
you
might
want
to
remove
that
nat64
translation.
Okay,
be
a
bit
further
root,
cause
analysis
trying
to
see.
Where
is
this
failure
actually
coming
from
so
we
saw
that
the
failure
is
actually
coming
from
both
same
origin,
cross,
origin
sources.
So
what
do
I
mean
by
same
origin?
J
So,
let's
take
an
example
in
this
plot:
let's
take
the
case
of
yahoo.com,
so
what
you
see
is
that
28%
of
the
content
for
yahoo.com
is
failing
over
v6,
so
I
want
to
know
how
much
of
this
28%
content
is
actually
coming
from
star
you
calm,
so
the
same
origin
source.
So
now
look
at
the
table
on
on
your
right.
You
will
see
that
ap
3%
of
the
stuff
that
is
failing
or
v6
is
coming
from
the
same
origin
source
so
start
calm.
J
So
Yahoo
can
do
something
about
this
right
and
if
you
look
at
the
top
of
the
horizontal
line,
you
will
see
that
12%
of
websites
have
more
than
half
of
their
content
coming
from
the
same
origin
source
that
feels
over
v6.
So
you
control
that
website.
We
can
do
something
about
this,
and
so
John
also
pointed
me
to
this
pointer
that
so
it's
largely
also
about
the
CG
and
infrastructure
which
is
or
which
is
hosting,
that
web
site.
J
So
the
CDN
infrastructure
also
has
to
turn
on
v6
for
all
the
web
page
elements
whether
they
are
same
original
cross
origin.
Okay,
then
we
also
looked
at
cross
origin
sources
so
stuff.
This
is
just
flipping
the
story
and
trying
to
see
what
cross
origin
sources
actually
fail
or
v6
for
a
web
site,
and
these
are
largely
third-party
advertisements,
analytics
websites,
user,
centric
websites,
starting
content,
and
this
is
all
the
stuff
that
is
actually
failing
or
v6.
J
Okay,
so
up
until
now,
we
have
been
largely
talking
about
failures,
so
complete
failures
and
partial
failures,
so
power
websites
which
actually
do
work
in
practice
or
both
over
four
and
six.
We
also
start
looking
at
latency
aspects,
and
this
this
is
something
that
we
have
been
doing
since
2013.
So
it's
a
four
year
long
dataset
by
latency
I
mean
TCP
connect
times.
So
it's
largely
measuring
the
amount
of
time
it
takes
for
the
connect
system
called
the
can
complete,
and
this
is
not
taking
into
account
DNS
resolution
time.
J
Okay,
and
so,
if
you
look
at
the
plot,
this
is
showing
you
latency,
four
minus
six.
So
if
you
see
anything
on
the
positive
scale,
that
means
that
v6
is
faster
for
those
web
sites
and
what
you
generally
see
is
that
back
in
2013
2014
situation
was
not
that
good.
So,
for
instance,
facebook.com,
which
is
the
green
line
on
the
top
plot,
it
was
like
hon
milliseconds
slower
over
six
than
over
four.
But
if
you
see
now,
things
seem
to
have
converged
to
0,
which
means
that
latency
is
actually
congruent
over
both
4
&
6.
J
So
you
don't
literally
see
any
difference
for
at
least
for
these
popular
websites.
So
in
a
separate
paper,
we
also
try
to
identify
why
we
had
inflated
lanes
latency
over
6
than
over
4
back
in
2013-14,
and
this
was
largely
happening
because,
when
you're
reaching
content,
you
were
hitting
a
Content
cash
and
the
ISPs
network,
which
was
not
dual-stack.
So
you
were
hitting
the
cache
over
4,
but
you
have
to
go
further
away
to
the
CDN
to
fetch
that
content
over
6,
which
was
increasing
latency
okay.
J
So
we
will
at
this
point
we
were
also
wondering
how
is
the
state
actually
looking
today,
and
so
this
is
the
state
of
latency
for
Alex
about
10,000
websites
that
do
work,
and
so
this
is
again
4-6
or
anything
on.
The
positive
scale
is
good
for
six,
so
you
see
that
actually
forty
percent
of
the
websites
are
foster
over
six
while,
like
ninety
four
percent
of
them
are
at
most
one
millisecond
slower.
J
So
this
is
really
good
news
and,
and
so
Alex
at
top
ten
K
I
would
assume
that
most
of
this
stuff
is
hosting
large
CDN
providers
like
Akamai
and
CloudFlare.
So
so
website
is
hosted
by
lot
CDN
players.
They
tend
to
show
no
no
difference
or
four
and
six
there's
all
again
a
longtail,
so
one
person
are
at
least
hundred
milliseconds
store,
but
I
would
assume
this
will
change
in
time.
J
Okay.
So
how
all
of
this
comes
into
the
picture
for
happy
eyeballs?
So,
given
that
we
have
this
for
you
long
dataset,
we
also
looked
at
the
entire
distribution,
so
blue.
So
if
you
look
at
the
top
plot,
you
will
see
that
this
is
raw
TCP
connect
times,
and
this
is
the
entire
sample
and
so
blue
is
blue
is
four
and
red
is
six,
and
what
you
see
that
see
is
that
only
one
percent
of
the
samples
were
ever
above.
J
The
happy
eyeballs
I've
see
six
five,
five,
five
timer
value
of
three
and
milliseconds,
so
it's
only
in
one
percent
of
the
cases
we're
happy.
I
was
actually
came
into
the
picture
when
deciding
whether
to
choose
four
or
six
and
the
repercussions
of
this
you
actually
see
in
the
bottom
plot,
where
you
see
that
or
almost
for
Alex
@mk
websites.
Ninety
nine
percent
of
all
those
web
sites
were
preferring
v6.
Ninety
eight
percent
of
the
time
and
which
is
good
news,
and
so
this
is
largely
leaving
two
percent
chance
for
v4
to
succeed.
J
J
So
at
this
point
we
started
wondering:
can
we
do
something
about
the
timer
value?
Okay,
so
what
happens
if
you
reduce
the
timer
value?
And
so,
if
you
look
at
the
top
at
the
bottom
plot,
you
will
see
that
at
this
point
we,
what
we
were
doing
was
we
were
controlling
two
parameters.
So
the
idea
of
happy
eyeballs
is
not
to
move
traffic
away
from
six
to
four
and
that's
why
we
didn't
want
to
compromise
on
the
preference
that
you
get
for
a
lecture
top
and
geared
side.
J
So
99%
of
they're,
like
certain
top
ten
key
websites,
should
still
get
preference
98%
of
the
time.
So
you
control
those
parameters
and
then
try
to
lower
down
the
timer
value
and
see
up
until
when
this
reference
holds,
and
this
is
what
the
plot
at
the
bottom
is
showing
you,
and
this
is
showing
that
up
until
138
milliseconds
it
tends
to
hold
and
after
which
it
tends
to
go
down.
J
L
A
J
C
J
J
J
Again
so
I
did
not
want
to
have
any
other
results,
biased
by
some
or
other
probes,
and
so
this
is
actually
showing
the
median.
So
this
is
general
behavior
as
seen
by
probes,
and
so
this
has
no
bias.
So
if
one
one
guy
decided
to
start
using
a
turtle
broker,
it
will
not
show
up
in
the
results
because
it
will
go
in
the
outlet
I'm.
C
J
C
I
think
it
could
be
interesting
anyway,
if
you
can
make
one
more
slide
or
something
explaining
from
the
n
number
of
probes
that
we
have.
There
are
two
or
three
that
are
using
two
no
broker
to
show
because
it
can
change
the
average
a
little
bit
not
too
much
but
a
little
bit
and
the
last
question
is:
you
are
not
considering
anything
else
and
happy
a
vol,
so,
for
example,
MTU
break
is
not
being
considered
in
this
measurement
right.
Yeah.
J
R
F
R
Measuring
with
your
partial
failures,
what
you've
kind
of
measured
is
a
reproach
to
lighting
up
content.
We
let
up
things
that
people
would
actually
maybe
want
to
see
first,
like
actually
real
content
and
for
secondary
domains.
The
page
is
requested
after
that
we
didn't
necessarily
chase
those
first,
so
we
got
to
them
eventually,
but
we
let
our
actual
content
first
and
things
like
say
advertisements
we
didn't
get
to
so
quickly.
O
O
You
had
suggested
a
number
of
150
milliseconds
as
a
proposed
latency
number
for
happy,
eyeballs
I,
know.
David
said:
please
come
and
help
us
co-author.
That
sounds
like
a
point
in
time.
Recommendation
yeah
and
that's
something
that
you've
actually
talked
about
earlier.
So
do
you
think
that
number
is
going
to
stay
about
150
milliseconds
for
the
lifetime
of
RFC
6
5
5
5
bits
or
is
that
do
we
need
a
mechanism?
That's
even
more
responsive,
somehow.
J
Yeah,
that's
a
very
good
question,
so
I
don't
I
hope
it
does
stay
constant,
and
this
so
Jeff
actually
asked
this
question
at
one
point
when
I
was
pressing
it
before,
and
so
what
is
actually
the
point
of
reducing
the
hyper
happy
eyeballs
timer
value?
The
point
is,
it
helps
us
to
know
when
we
can
turn
off
v4.
So
if
we
can
turn
down
the
happy
eyeballs
timer
to
zero
and
still
the
traffic
does
not
move
from
6
to
4,
then
we
know
we
can
actually
turn
off
4.
L
David's
colossi
Apple
we're
actually
going
in
the
exact
opposite
direction.
So
first
point
I
agree
that
having
a
fixed
value
is
not
the
best
thing.
So
what
we
have
in
our
OS
is
we
use
the
measured
RTT
to
inform
what
the
timeout
should
be.
So
it
depends
on
if
we've
been
doing
networking
for
a
while,
we
have
a
much
more
granular
value
so
that
our
see
6,
5,
5
5
best
recommends
doing
that
as
well.
But
actually,
what
we're
doing
is
not
reducing
this
timeout.
L
We're
increasing
it,
because
what
you're
doing
when
you're
reducing
it
is
you're
increasing
your
chance
of
going
over
v4,
which
is
not
what
you
want.
The
only
purpose
of
happy
eyeball
is
to
catch
these
failure
modes
that
you
described
when
v6
doesn't
work
and
those
are
getting
as
your
numbers
show
rarer
and
rarer.
So
when
hope
you
have
those
fires
and
you're
close
you're.
L
J
Okay,
so
the
so,
there
are
two
points
made
in
that
comment,
so
the
first
point
actually
agree
with
so
having
a
dime,
dynamic
time
or
value
might
be
very
useful,
because
then
we
don't
have
to
update
our
xev
now
and
then
using
the
latency
or
RTP.
History
might
be
useful
as
well.
So
I
completely
agree
with
that.
J
So
if
we
can
do
this,
then
then
we
don't
need
a
fixed
timer
and
then
we
had
done
and
for
the
second
part
I'm
just
wondering
so
happy
eyeballs
was
wasn't
it
wasn't
it
designed
to
actually
quickly
fall
back
when
you
actually
see
failures
right
and
if
you
keep
on
increasing
the
timer,
then
you
actually
don't
need
happy
about,
because
you
are
back
to
the
same
story
where
you
see
long
time
outs,
which
we
were
actually
seeing.
Therefore
happy
eyeballs.
J
So
so
the
idea
is
to
the
idea
has
to
not
move
traffic
away
from
six
to
four
and
given
that
six
seven
to
four
gives
us
this
preference
to
choose
six
and
in
cases
where
you
see
of
where
you
see
failures,
you
should
be
able
to
quickly
fall
back,
but
that
how
quickly
you
want
to
fall
back
is
something
that
we
have
to
decide.
So
if
we
keep
this
too
long,
then
we
are
back
to
the
same
story
where
we
are
not
falling
back
quickly.
L
E
Ron
Zook
already
as
as
someone
who
was
involved
with
the
first
happy
eyeballs
implementation
that
got
shipped,
which
was
done
in
chrome,
the
300
millisecond
timer
was
chosen
because
we
already
have
a
250
millisecond
timer
and
we
wouldn't
want
to
get
confused
by
looking
at
the
graphs.
That
is
the
engineering
that
happened
now,
the
you
know
you
might
think
that
was
dumb,
but
in
reality
the
the
thought
was.
It
was
not
intended
as
a
performance
optimization.
E
It
was
intended
as
a
fail-safe
and
it
was
never
intended
to
be
almost
as
fast
as
you'd
notice
would,
but
it
was
kind
of
intended
to
be
well.
You
know
something
is
wrong
and
we're
not
gonna,
try
and
bend
over
backwards
to
make
it
right.
So
there
are
other
implementations
that
have
historically
been
more
or
less.
E
You
know
ruthless
I
mean
the
Microsoft
implementation
says
this
network
isn't
working
I'm
just
gonna
give
up
never
use
b6
the
Apple
one
was
very,
very
sort
of
like
in
yeah,
it's
very,
very
intention
to
like
maintain
performance
at
all
times.
One
point
that
I
wanted
to
make
is
that
if
you
set
the
time
to
zero,
you
use
V
for
50%
of
the
time
exactly
so.
Setting
the
timer
to
zero
is
never
a
goal
right,
yeah.
So
to
be
honest,
I,
don't
think
that
300
milliseconds
are
a
problem
here.
I
mean
I.
E
J
So
I
just
want
to
point
out
to
the
fact
that
you
were
saying
it
50
percent
you
will
see
using
before
and
that's
what.
Actually,
the
plot
shows
you,
because
the
50th
percentile
is
actually
hitting
in
the
middle.
So
so,
if
you
lower
the
time
or
value
to
zero,
half
of
the
stuff
will
go
over
for
yeah,
because.
E
O
Hi,
my
name
is
Lee
Howard
I'm
here,
with
that
I
had
on
I've
been
asked
to
do
a
presentation
thanks,
Warren
I
appreciate
the
offer
of
the
hat,
but
I'm
not
taking
your
hat,
no
I'm,
not
taking
the
area
director
hat
so
a
couple
months
ago,
I
was
asked
if
I
would
contribute
some
information,
some
slides
to
about
what
is
the
state
of
ipv6-only
on
the
internet,
and
this
was
for
a
series
of
actually
some
of
our
working
group
chairs
and
so
I.
Did
that
and
a
couple
people
said:
that's
really
interesting
work.
O
Would
you
share
that
more
broadly
am
I've
written
a
blog
post
about
it,
but
here's
some
of
the
slides,
the
first
couple
of
slides
are
things
that
most
of
us
have
seen
already,
but
in
case,
but
not
everybody
has
the
entire
history
that
some
of
us
do.
So,
if
you've
never
seen
this
I've
got
all
the
URLs
at
the
bottom.
Google
is
doing
some
active
measurements
of
ipv6.
This
is
connections
that
they
see
from
you
know:
people
hitting
Google
Sites
over
ipv6
and
so
we're
up
to
just
about
20
percent
worldwide.
O
That's
pretty
fantastic
and
you
can
see
it's
up
to
the
right.
The
important
thing
on
this
one
is
this
and
I
think
we
I
think
the
previous
presentation
described.
There's
this
weekly
change,
so
weekends
are
higher.
Weekdays
are
lower
because
enterprises
are
lagging
on
v6
deployment,
so
that
distinction
is
pretty
significant.
So
that's
probably
where
we
got
to
pay
some
attention
on
the
same
site,
different
tab.
You
can
see
that
there
are
lots
of
countries
that
have
various
levels
of
v6
deployed.
O
They
color
things
red
when
there's
a
higher
latency
over
v6
ice
Hawk
is
doing
has
been
since
world
of
u6
launch
has
been
collecting
statistics
from
several
content
providers
and
sort
of
blending
them
together,
and
they
provide
these
numbers.
You
can
click
on
any
of
those
sites
and
see
that
provided
that
ISPs
performance
or
or
their
their
v6
deployment
over
time,
pretty
good
numbers
there.
O
Obviously
these
are
the
top
ten
they're
sorted
by
a
number
of
eyeballs,
not
by
percent
of
deployment,
because
by
number
of
over
v6
Eric
Vika
is
doing
some
fantastic,
pushing
it
to
glom,
eration
I.
Suppose
of
some
of
this
data
on
the
left
side
is
top
countries.
This
is
measuring
the
the
top
the
Alexa
top
50
for
each
country.
What
percent
at
the
top
50
have
ipv6
he's,
got
it
weighted
and,
and
the
the
green
column
is
is
number-
is
the
raw
number
of
the
top
50
that
support
v6?
O
The
weight
number
I
believe
is
weighted
by
number
of
DNS
hits.
So
that
is
a
sort
of
way
to
say
how
important
are
the
v6
enabled
sites
so
a
higher
percentage?
There
means
those
are
the
more
important
sites
there
might
be
at
all.
A
sharp
drop-off
the
countries
here
to
me,
it's
very
interesting.
There's
some
very
small
countries
here
in
some
cases
are
surprising.
Wow
they've
got
you
know.
I
wouldn't
have
thought
that
Tonga
would
be
a
great
leader
in
ipv6,
necessarily
not
the
Tong
is
not
a
great
country.
O
What
we're
seeing
is
that
the
top
50
sites
tend
to
be
hosted
by
companies
like
Google
in
those
countries
and
therefore,
since
Google
has
a
lot
of
their
properties.
Ipv6
enabled
Tonga
has
a
lot
of
their
top
web
sites.
Ipv6
enabled
the
right
column
is.
Is
ISPs,
so
this
is
again
the
eyeball
measurement.
This
is
taken
from
I
think
this.
This
comes
really
taken
from
Google's
data,
and
so
you
can
see
you
know,
hey!
Congratulations
out
what
a
surprise
that
Belgium,
where
Eric
lives,
has
the
most
eyeballs
enabled
over
ipv6.
O
Who
would
have
thought
that,
but
I'm,
you
know
fairly
satisfied
with
with
the
United
States
being
second
in
something
he
also
on
that
site
has
a
place
where
you
can
do
extrapolations
from
this
data
over
time,
and
you
can
extrapolate
based
on
websites.
You
can
use
Google's
data,
you
can
use
Akamai's
data,
you
can
use
ap
and
X
data
here,
I've
taken
and
actually
Lorenzo
the
one
who
convinced
me
that
an
s-curve,
a
logistic
curve
is
the
way
to
do
this,
because
adoption
curves
tend
to
be
these
kinds
of
s,
curves.
O
Now,
of
course,
any
kind
of
prediction.
It
depends
on
what
kind
of
assumptions
you
make
so,
but
still
it's
fun
to
play
with
this
particular
tool
here.
I've
taken
worldwide
measurements,
as
seen
over
seen
by
Google
and
said,
based,
lasts
the
entire
history
of
data
that
we
have
show
me
3,000
days
into
the
future.
Where
we'll
be
we
need
for
ipv6
deployment
and,
according
to
current
extrapolation
on
this,
we
hit
50%
worldwide
users
with
ipv6
in
September
2019.
That's
only
two
years
away.
50%
of
the
users
worldwide
would
have
that
BB
6
in
two
years.
O
That's
still
feeling
pretty
good
I
think
we
can
feel
pretty
satisfied
with
that.
Obviously,
these
numbers
change
go
plug
in
your
country.
You
can
do
this
by
country
plug
in
your
country,
and
you
will
find
where
your
country
goes
over.
The
future
I'm
great
again
satisfied
with
the
curb
on
the
US
ap
neck
has
data.
This
is
just
one
of
the
many
tables
that
they
present.
This
is
present
by
various
regions.
A
peenics
I'm,
not
gonna,
get
into
the
methodology,
but
it's
they're
doing
ads
on
Google
properties
so
that
they
can
get
users
actual.
O
O
from
ISPs
and
it,
but
I've
sorted
this
by
the
percentage,
ipv6
capable,
usually
I,
sort
by
the
number
of
samples,
because
that
gives
me
a
sort
of
a
rough
idea
of
how
important
sites
are,
how
the
most
important,
ISPs
or
networks
are
doing
in
the
I
pin
in
the
US
here,
I've
sorted
by
ethnicity,
because
I
wanted
this.
You.
S
Morally
george
martynuk
enoch,
you
morally
want
to
arise
with
your
men
in
black
eraser
the
top
entry
there,
because
that's
an
artifact
of
a
glitch
in
advertising
exposure
and
Facebook's
decision
to
put
their
own
IPs
behind
the
ads
that
were
being
served.
So
can
we
all
just
pretend
we've
had
the
men
in
black
pen
pointed
at
us
on
Facebook
and
not
a
million
and
a
half
samples
I'm
satisfied
with
that
moral.
O
A
O
S
That's
you
think
your
turn,
so
you
gave
me
a
throwaway
comment
in
the
corridor.
Last
night,
yep
I
believe
that
the
10%
uptick
that
you
have
on
your
graphs
is
because
of
charter
Cox
doing
some
stuff
I,
just
looked
at
three
of
their
is,
is
you
are
on
the
money,
late
yeah?
He
called
it.
I
called
it
yeah.
So
what
he's
asking.
O
About
is
yesterday,
I
was
looking
at
their
charts,
which
I
haven't
included
here
and
I
saw
that
the
US
has
jumped
by
somewhere
between
five
and
ten
percent.
The
number
of
users
deployed
in
the
last
two
or
three
months.
Five
to
ten
percent
deployment
in
three
months
is
incredible,
especially
a
country
the
size
of
the
US
and
is
down
to
two
companies,
Charter
and
Cox.
Second
and
third
largest
cable
companies
in
the
US,
and
so
I
was
actually
on
ready.
O
Yesterday,
somebody
was
complaining
that
they
wanted
to
shame
charter
for
not
deploying
ipv6
and
I
said,
look,
there's,
hope,
here's
data,
the
reason
I
can't
keep
showing
this
chart,
though-
and
this
is
by
the
way
I've
actually
done
some
cherry-picking
here.
This
is
not
the
top
twenty-five
or
whatever
list
of
networks.
This
is
some
that
looked
interesting
and
representative
to
me
of
what's
in
the
the
top
sort
of
sixty
percent
and
above
ipv6
capable
and
the
reason
I
did,
this
is
I
want
to
sort
of
characterize.
O
So
so,
first
of
all,
I
wanted
to
say,
look
a
network
that
has
ninety
eight.
Ninety
nine
percent
of
their
users,
v6
enabled
is
a
network.
That's
essentially
ready
for
ipv6
only
they
can
turn
off
ipv4
if
the
only
reason
they
haven't
is
because
the
rest
of
the
internet
isn't
ready.
In
fact,
they
might
be
ready
to
go
for
to
some
kind
of
v6
only
plus
translation.
Some
of
these
may
be
doing
that
already.
We
don't
know,
but
I
also
want
to
point
out
some
of
the
sort
of
typical
demographics
of
these
networks.
O
So
we
have
some
some
ISPs
like
Midwest,
9x
I'm,
assuming
as
part
of
Verizon
I,
don't
know
what
is
9x
anymore
we've
got
and
then
we
have.
You
know
Google
actually
think
Google's
on
here
a
couple
of
times
Verizon's
on
here
a
couple
of
times.
We
have
several
universities
and
I've
only
included
a
few
of
them,
because
a
lot
of
universities
have
done
major
deployment
of
of
ipv6
and
what
I
find?
O
O
O
O
O
So
actually
Fred
pointed
this
data
out
to
me:
Hurricane
electric
does
lots
of
measurements
they're
fantastic,
they
put
them
all
in
the
web.
They
hide
them
pretty.
Well,
though,
so
this
one
is
a
list
of
a
SNS
and
what
kind
of
prefixes
they're
announcing
which
address
family
guess
what
359
a
SNS
are
announcing,
ipv6
only
no
ipv4,
that's
an
astounding
number
I
was
shocked
when
I
saw
that
number
there
are
359
networks
that
are
ipv6
only
on
the
internet.
O
M
I've
deployed
multiple
networks
where
we
announced
v6
a
space
because
we
can
get
it
and
then
we
have
a
slash
28
from
our
upstream
for
stuff,
including
nat64,
and
we
obviously
don't
analysis.
It's
not
ours.
So
I
wouldn't
say
those
networks
are
v6.
Only
really
they
just
so
right.
They
just
don't
know
how
to
announce
a
visa,
they
don't
have
any
v4
to
announce
and
they
don't
can
so
hey.
O
You
kind
of
eat
well,
so
yeah
I'm
gonna
come
back
to
at
the
end
of
this.
What's
the
definition
of
v6
only
because
that's
sort
of
been
going
on
in
the
list
also,
but
I
will
say
that
many
of
these,
like
I've,
done
few
spot
checks,
I
have
enabled
do
it
systematically,
but
the
spot
checks
they
tend
to
be
research
or
academic
networks.
O
Many
of
them
not
all
the
ones
that
I've
looked
at,
and
so
it
wouldn't
surprise
me
too
much
to
know
that
a
research
network
is
deploying
an
ipv6
version
of
their
network,
either
as
their
next
generation
network
or
as
as
just
as
a
parallel
way
to
manage
their
their
their
their
ipv4
and
ipv6
address
family
networks.
Still
a
half
a
percent
of
asns
using
announcing
ipv6
only
I,
don't
think,
is
completely
nothing,
especially
since
I.
O
First
did
this
like
I,
said
a
couple
of
months
ago
and
as
I
was
updating
this
earlier
this
week,
constantly
Tuesday
I
found
that
that
numbers
actually
grown
measurably.
You
know
from
0.55
percent
of
ASNs
being
basics,
only
two
point:
six
one
percent
of
SN's
being
fixed
p6.
Only
that's
not
nothing!
There
that
might
be
that
most
of
the
new
asns
are
coming
up
v6
only,
but
I
haven't
been
able
to
confirm
that
either.
Just
you
know,
cycles
we've
seen
this
slide
before
I'm
gonna
whine,
pointing
at
David
because
it
was
Tommy
who
presented
it.
O
But
this
is
you
know
this
is
an
in
map
our
G,
the
rise
of
v6
only
hosts
look.
There
are
indeed
v6
only
hosts.
This
was
at
IETF.
I
attribute
this
to
initiatives
like
we
heard
Marcus
earlier,
we've
heard
folks
at
Cisco
talking
about
their
v6
only
building
and
their
project.
We've
talked
about
heard
from
terrace
tree
and
being
a
v6
sort
of
testbed
network.
There
doing
interesting
things,
they're
a
t-mobile.
Of
course.
That's
no
surprise
LinkedIn
Facebook
we've,
you
know
everybody
has
talked
about
this.
O
My
company
is
doing
translation
is
a
service
I,
believe
it
there's
going
to
be
v6
only
and
I
should
be
doing
and
there's
there's
room
here
for
for
work
to
be
done.
So
what
are
the
reasons?
Well,
we've
just
seen
more
measurements
on
latency
we've
got
tons
and
tons
of
data
now
of
reports
from
the
field
saying
that
v6
is
at
least
often
faster
than
before
in
terms
of
latency.
O
O
Marcus
was
talking
about
some
of
his
reasons
for
easy.
These
six,
certainly
that's
there
I
gotta,
say
if
you
haven't
I
mean
probably
many
people
here
have
done
this,
but
if
you've
tried
submitting
in
v4
and
doing
the
math
between
you
know
dot
one.
Ninety
two
two
two
two
three
and
what's
the
Matt,
you
know
how
what
are
the
hosts-
and
you
know,
trying
to
add
32
bits
to
something
in
the
oh
man.
You
know
math
is
hard.
You
do
this
in
v6
and
it's
it's.
It
turns
out.
O
It's
really
easy
once
you
get
the
hang
of
it,
which
is
ten
minutes
of
practice
segment.
Rounding
is
a
cool
new
application.
You
can
do
interesting
things
like
number
you've
got
so
many
addresses
you
can
use
address
as
this
process
at
ease.
You
can
use
addresses
as
service
bits,
so
there
are
cover
things
that
you
can
do
once
you
enable
that
I'm
sure
it
actually
there's
a
ski
left,
but
he's
got.
You
know
lots
of
his
own
reasons
that
he's
talked
about
in
public
too.
O
O
Let's
do
an
extrapolation
see
where
we'll
be
in
in
five
six
years
now
the
definition
ipv6
only
this
is
not
necessarily
a
conversation
that
you
have
to
have
I
would
look
to
the
co-chairs
to
actually
not
my
co-chairs,
because
I'm,
not
a
chair
right
now,
I
will
look
to
the
chairs
to
decide
whether
we
want
to
have
a
conversation
on
this
right
now.
My
proposed
definition
is:
if
the
host
has
no
ipv4
address
provisions
on
it.
It
is
an
ipv6
only
host
and
therefore
there
might
be
help
for
the
host,
but
the
host
is
v6.
H
Being
nice
to
you,
George,
okay
and
second,
point
I'm,
afraid
it's
a
kind
of
other
statement
to
say
if
90
plus
percent
of
your
eyeballs
I
seen
over
v6,
we
are
ready
for
v6
only
because
there
are
things
which
still
might
be
might
depend
on
before
inside
right
and
but
if
it's
true,
it
would
be
really
interesting.
What
we
seen
for
this
HF
network.
E
Clearly,
equivalent
b6
only.we
well,
when
you
said,
when
you
put
Android
on
v6
only
network
with
a
matte
6-4,
it
actually
does
manufacture
synthetic
ipv4
address.
So
I
would
like
to
have
to
be
considerably
6l
me.
So
you
say
if
the
network
doesn't
provide
a
V
for
the
rest
of
the
host,
but
I
have
a
feeling.
Joy
is
gonna,
say
something
similar
couple
of
things:
could
you
could
we
go
back
several
slides
to
the
enterprise
like
slide
to
this
or
to
the
Google
beta
site?
Anybody
all
the
way
back.
E
One,
yes,
so
what
percentage
variation
is
that
and
has
it
been
changing
over
time?
Has
it
been
going
up
or
down
I,
don't
know
the
answer,
but
it
would
be
a
useful
answer
because
you
know
you
know.
Maybe
there
is
deployment
in
the
enterprise
just
because
that
you
knows
that,
like
variation
is
increasing,
doesn't
mean
it's
increasing
in
a
percentage,
because.
O
B
E
E
S
O
Labs
ap
Nick
did
a
we're
doing
a
cat,
I
have
a
blotch,
and
maybe
it's
not.
Maybe
it's
not
a
phoenix.
Maybe
it's
some
guy.
We
know
who
works
for
ap
Nick
on
pet,
a
blog
where
he
was
showing
the
run
out
on
ipv4.
That
might
be
a
useful
projection,
an
ongoing
daily
site,
yeah
yeah
I.
Finally,
that
guy
was
tracked
at.
O
O
Thought
of
that
too
yeah.
It
does
change.
It's
also
really
interesting
to
see.
We
know
we
get.
You
know
annual
spikes
of
utilization
right
around
the
holidays,
the
the
the
winter
holidays,
because
people
aren't
at
work
and
therefore
they're
at
home,
and
they
do
a
lot
of
surfing,
and
then
we
get
a
little
dip
in
January
February,
because
nobody
is
deploying
new
stuff
in
January,
February
they're
catching
up
with
their
holiday
moratoriums.
A
A
Data
point
or
interesting
to
me,
I
was
looking
at
the
ipv4
market
group
know
it
before
addresses
are
real
estate
than
they're
a
real
estate
agent
they're,
trying
to
sell
solar
product,
and
their
estimate
was
that
the
price
of
the
90
before
address
would
start
to
fall
in
about
2019,
because
there
would
be
enough
ipv6
saturation
that
the
interest
in
v4
would
fall
off.
There's
an
that.
O
C
Palette,
my
prediction
on
this
and
I
will
explain
why
in
a
minute
is
that
by
2020
will
be
about
70%,
not
50%?
Okay,
why
I
believe
that?
Because
what
typically
happens
is
when
a
network
starts
deploying
ipv6,
because
the
major
service
providers
at
content
providers
delivery
networks,
things
like
that
are
already
pv6-
enable
the
traffic
jam
is
not
like.
This
is
like
going
that
way.
I
think!
That's!
That's
that's
going
to
happen
in
a
small
content
providers
provide
a
pv6
service
or
enable
a
PVC
servicing
that
the
network's
that
trend
will
increase
quickly.
O
Because
of
the
law
of
large
numbers
that
many
of
the
largest
networks
live,
all
networks
worldwide
have
deployed
ipv6
and
are
not
gonna
have
skyrocketing
shoot
numbers
shooting
up.
So
now
we
have
to
wait
for
lots
of
small
ISPs
to
deploy
ipv6.
Now
they
may
all
say
20
teams
the
year
we've
been
out
of
addresses
at
the
are
IRS
for
two
years.
We
are
hordes
are
gone
and
therefore
we
gotta
go,
but
yes
predicting.
C
Second
point:
regarding
the
ipv6:
only
a
SMS
I
have
some
customers
very
few,
but
some
especially
new
ISPs
or
new
business
having
their
own
ASM
that,
because
they
cannot
get
more
rapid
for
addressing
a
space,
they
are
using
address.
I
did
for
addressing
a
space
from
their
upstream
providers.
Okay,
so
that
may
explain
a
little
bit
this
and
probably
is
going
to
happen
more
and
more.
O
C
T
Michael
Abramson
so,
but
the
whole
v6
only
host
so
I
think
we
should
differentiate
between
the
host
and
the
access
so
like
in
t-mobile.
That's
not
a
v6
only
host,
but
it's
a
v6
only
access
yeah,
so
they
do
provide
dual
stack
access.
Disease
tunneled,
so
it
has
to
do
with.
Like
is
the
device
capable
of
sending
native
ipv4
packets
on
its
axis?
That
should
be
like
the
that
part
of
the
definition
definition
and
then
you
have
the
host
tanning
talk
to
IV
v4
space.
T
If
it's
can
talk
to
up
in
the
first
place,
I
don't
think
it's
an
ipv6
only
host,
but
it's
on
an
IPS.
It's
only
access,
so
I
think
we
need
to
differentiate
this
I.
Don't
want
to
talk
about
the
addresses
really
that
the
device
has,
because
if
it
hasn't
in
ipv4
address
on
a
tunnel
interface
that
it
means
that
he
can
send
tunnel
like
these
four
packets
over
ipv6
access.
It's
not
an
ipv6.
Only
host
I
think
in
a
v6.
Only
host
should
have
zero.
T
J
About
my
sweetie,
you
Minnick,
so
I
do
also
want
to
give
a
plus
one
to
having
a
definition
for
v6.
Only
because
this
is
this
is
creating
so
much
confusion
on
the
internet
and
people.
People
just
refer
to
v6
only
when
they
mean
something
v6,
only
with
translation,
with
translation,
and
then
you
have
to
contact
the
authors
to
try
to
understand
what
they
mean.
I,
don't
really
care,
whether
it's
a
non
adjective
or
we
have
to
differentiate
it,
but
having
it
somewhere.
O
Something
I
think
I'm
hearing
is:
if
there
is
a
newcomer
in
the
room
who
is
looking
for
an
internet
draft
to
write,
the
definition
of
ipv6
only
would
be
one,
and
there
are
several
of
us
here
who
would
probably
be
happy
to
help
you
through
the
process
and
and
and
get
that
published.
Also,
if
there's
somebody
room
who's,
looking
for
a
small
research
project
going
through
the
359
asns
to
see
if
they
have
comparable,
v4
ASNs
or
maybe
trying
to
figure
out
why
their
v6
only.
That
would
also
be
interesting
and
useful
research
Victor.
D
D
Give
an
example,
I'm,
not
sure
v6
20
core
is
that
is
that
a
thing
we
care
about
anymore,
like
is
a
really
significant
technical
barrier,
so
making
a
core
v6
home
right,
I
I
think
we
should
connect
it
to
hardening
whatever
whatever
the
key
objective
is
right,
I
mean
we
knew
for
a
long
time
getting
SP
networks
and
accesses
to
v6
because
of
the
complications
of
home
networks,
etc.
That
was
important,
so
we
that's
an
objective.
D
C
B
B
Okay,
Ross,
White,
LinkedIn,
Zaid
and
John
are
co-authors
on
this,
not
a
whole
lot
of
changes.
Since
the
last
time
we
saw
this
presentation
just
some
comments
off
the
list.
Remove
some
deceptions
things
like
that.
The
purpose
of
this
is
to
take
advantage
of
the
v4
v6
transition
through
which
changes
in
the
network
protection
can
be
looked
at
and
provide
a
set
of
suggestions,
new
requirements.
That
providers
would
like
to
see
implementers
do
in
their
routers
around
support
now.
B
I
know
that
there
are
edge
router
drafts
as
well
Orbis
going
on
the
draft
since
the
last
change.
We
went
working
group
document
since
last
IETF
and
there
have
been
a
lot
of
changes
and
should
must
based
on
feedback
from
people
off
and
on
list.
So
you
should
look
for
that.
Everything
that's
involved
in
the
slides
is
something
that's
changed
since
the
last
one,
the
stuff-
that's
not
in
bold,
is
stuff.
That
was
in
the
last
presentation,
review
their
architecture,
some
stuff
about
Rivest.
B
This
principle,
complexity,
layer
structure
and
routers
haven't
had
a
lot
of
comments
on
that
text.
Requirements
related
the
device,
management
and
security
had
some
comments
about
yang
stuff.
Some
don't
like
the
yang
properly
I'm
tending
to
leave
it
in
there
myself,
because
I
don't
care
what
think
anyway,.
N
B
In
forgot,
console
support
was
one
that
came
up:
zero
touch
provisioning.
There
was
a
huge
argument
on
the
list.
Frankly,
I
did
not
read
all
the
messages
it
was
TR
and
but
the
upshot
is
is
that
the
draft
now
says
DHCP
and
slack
must
both
be
supported
by
default
and
slack
must
be
supported
and
enabled
by
default.
Lots
of
new
text
in
this
area.
I
would
really
appreciate
any
feedback
on
this
because
I
know
this
is
a
very
contentious
area
and
a
lot
of
people
have
very
strong
opinions
about
it.
B
So
I
want
to
make
sure
that
this
section
of
the
draft
is
right.
There's
some
protection
against
it
all
stuff
in
there
didn't
get
a
lot
of
comments
on
that
requirements.
Related
limitary,
some
people
again
said
about
yang
G
RPC
is
in
there
other
things
like
this.
This
section
Q
probably
gives
more
definition.
If
there
are
comments
coming
off
the
list
for
this
I
haven't
seen
a
lot.
B
Topology
State
and
traceability
flow
traceability,
stuff,
like
this
requirements,
related
ipv6,
porting
and
dressing.
This
sections
draft
is
also
pretty
light.
In
my
opinion,
right
now,
I
could
use
some
more
how
future
consideration
segment,
routing
I
haven't
put
text
in
there
yet
but
I'm,
assuming
that
we're
going
to
want
all
routers
to
support
segment,
routing
and
some
type
security
considerations.
I
think
is
a
pretty
good
section
at
this
point
has
a
good
bit
of
stuff
in
it
and
then
there's
a
conclusion:
we've
accepted
as
a
working
your
dot.
B
Please
just
look
and
make
suggestions
for
empty
text
sections
and
give
us
suggestions
on
anything
else.
We're
really
looking
for
feedback
on
this.
We
want
this
draft
rewrite
and
we
want
to
push
it
forward
so
that
we
can
the
providers
sitting
in
the
room
can
tell
the
vendors
and
the
folk
like
fr,
Freeman,
trotting
and
other
OpenStack
routing
stuff
going
on.
Please
tell
us,
you
know
we're
trying.
The
providers
are
trying
to
tell
these
people
what
it
is.
B
F
T
T
B
Q
U
Labs
if
this
document
this
seems
like
it
might
need
some
more
suggestions.
One
thing
that
came
up-
and
somebody
said
you
should
just
go
to
the
mic
rather
than
write
a
mail,
but
anyway
the
idea
is
either
way
shouldn't
this
say
a
little
bit
more
about
issues
related
to
RFC,
79
34,
the
the
providing
multiple
addresses
it's
kourt's
I
know.
B
B
E
F
E
That
seriously
the
the
actual
Ted
lemon
says
this
has
said
this
about
20
times,
480
106.
If
you're
a
Rooter,
it's
clear
what
it
means
you
have
to
be
able
to
announce
it
for
dhcpv6.
It's
not
clear.
It
means
like
what
use.
Does
it
mean
that
you
support
it
as
a
client?
Does
it
mean
that
you
support
a
DHCP
server
and.
E
B
E
A
You
ahead
of
schedule,
Fred!
Thank
you.
A
L
The
problems
that
happy
eyeballs
do
not
solve
and
we'll
finish
on
next
steps
for
this
document.
So
one
of
the
main
differences
between
happy,
eyeballs,
v1
and
v2
is
the
a
synchronicity
of
DNS.
What
that
in
the
original
document
it
never
really
discussed.
Yes,
I
just
assumed
that
you
had
results
and
one
of
the
ways
it
says
you
could
do
that
was
to
use
get
out
our
info
accept
what
get
our
info.
Does
it's
easy?
L
It's
a
synchronous
blocking
call
that
sends
out
an
a
query
aquatic
we're
either
separate
packets
and
waits
for
both
for
pots.
And
if
you
get
as
you
can
see
here,
the
quad
a
really
quickly,
but
the
a
is
out
to
lunch.
You
can
just
be
sitting
there
for
a
very
long
time
before
you
actually
start
sending
TCP
sets
and
that's
just
not
efficient.
So
what
the
new
document
proposes
is
to
instead
far-off
your
queries
when
you
get
the
reply,
so
you
don't
need
to
kind
of
unify
as
a
bottleneck.
L
When
you
get
your
quad
a
response,
you
can
start
the
tcp/ip
v6
and
when
you
get
your
a
response,
you
could,
if
you
wanted
to
start
the
TCP
syn
for
ipv4.
So
the
specific
algorithm
looks
a
little
bit
more
like
this.
So
since
we
want
to
prefer
ipv6
when
you
get
the
quad
a
response,
you
start
up
you
v6
and
immediately
and
one
when
you
get
the
asynchronously
later.
L
You
add
it
to
the
list
of
addresses,
and
so
then
it
involves
the
timers
that
we
were
discussing
a
little
earlier
today,
like
300
milliseconds
or
so.
One
of
the
things
we
observed
operationally
is
that
even
if
you
send
the
quad
a
query
first
in
the
a
query
you
write
like
back
to
back
right
after
it,
they
very
often
get
reordered
either
ordered
by
the
network
or
probably
just
by
threading,
on
the
one
of
the
TMS
you
pressing,
resolvers
or
off
authoritative
servers.
L
A
L
Wait
a
little
bit
to
see
if
the
Koala
is
in
the
pipe
and
if
we
get
the
quarter
during
that
time,
then
we
start
the
v6
and
just
put
the
v4
later
on
the
list.
If,
however,
after
50
milliseconds,
we
don't
have
it
odds,
are
the
quad
a
query
or
the
reply
got
dropped
by
the
network?
So
let's
not
wait
a
full
second
for
the
DNS
root
transmission.
Let's
start
yet.
L
L
L
So
if
you
hit
the
same
server,
you
have
better
odds
of
reusing
a
session,
take
care
of
something,
whereas
if
you're
a
new
one,
you
may
have
to
do
the
full
exchange
again
and
if
you
want
to
just
sort
all
the
addresses
that
you
got.
Let's
say:
8
ipv6
addresses
in
a
type
e
v4
you'd
end
up
most
often
putting
all
the
v6
addresses
first
and
then
all
the
v4
and
then,
if
you're
waiting,
say
300
milliseconds.
That
ends
up
being
a
lot
until
the
first
before
so
then.
L
What
you
do
is
you
grab
the
first
address
from
the
second
family,
so
the
first
ipv4
address
yank
it
out
and
put
it
up
in
the
second
or
third
position
that
way.
You're
gonna
still
fall
through
their
v6
ones,
but
you
still
hit
the
v4
in
case.
Your
v6
is
completely
busted.
The
number
of
these
six
addresses
doesn't
delay.
L
This
is
also
a
slight
change
from
the
original
happy
eyeballs
RFC,
because
that
one
only
ever
discussed
hitting
the
two
first
addresses
the
first
e61
in
the
first
before,
as
it
turns
out
one
of
the
reasons
when
you
do
a
DNS
query
for
say
google.com.
One
of
the
reasons
they
give
you
a
bunch
of
addresses
is
that
you
can
failover
between
them.
If
one
of
them
happens
to
be
down,
so
this
document
recommends
going
through
the
entire
list
until
the
first
one
can
access
and,
as
we've
seen
operational
data,
ninety
something
percent
of
the
time.
L
L
Opening
connections
creates
state
and
so
you're
adding
load
on
the
network
for
no
reason
so
having
a
small
delay
on
the
order
of
a
hundred
milliseconds
to
a
second
allows
you
to
still
fall
back
in
a
way
that
the
user
won't
find
unbearable,
but
still
will
avoid
overloading
the
network.
So
what
we
actually
end
up
doing
in
our
stack
when
we
have
this
historical
RTT
data
from
previous
TCP
connections
to
this
either
host
or
similar
route,
we
take
the
mean
of
the
RTT
plus
4
times
the
variance
a
way
to
think
about.
L
L
So
if
your
sin,
basically,
if
we
start
off
the
v6
N
and
after
a
while,
we
go
no
reply,
that's
fishy
and
we
resend
the
syn
to
that
address
in
case
he
got
lost
it's
at
the
same
time
that
we
send
this
in
for
the
next
address,
and
that
way
you
can
kind
of
stagger
them
to
avoid
putting
load,
but
soul
react
wrote
pretty
quickly.
We
also
have
a
lower
bound
on
this.
That's
a
hundred
milliseconds!
L
L
So
the
first
one
is
ipv4
literals,
like
a
user,
can
type
in
an
ipv4
address
into
their
HTTP
browser,
and
you
can't
just
drop
that
on
the
floor.
They
want
that
to
work.
So
what
you
do,
then?
You
use
the
discovery.
You
discover
the
IP
v
dynastic
for
prefix,
so
that's
documenting
RC
70/50,
and
then
you
combine
that
prefix
with
the
v4
dress
to
basically
do
the
dns64
type
operation
locally,
that's
documented
in
RFC
6050,
and
that
actually
works
pretty
simple
and
it
works
really.
Well.
L
We
also
added
an
API
for
this.
If
you
call
get
out
of
info
with
the
v4
address,
it'll
do
all
the
work
for
you
on
our
platforms,
another
failure
mode
that
we've
observed,
that
is
pretty
rare,
but
still
noticeable
enough.
That
people
complain
loudly
is
host
names
that
have
party
records
that
are
bogus
and
I'm.
Not
talking
like
the
the
ones
that
have
completely
bogus
them,
we've
seen
quanti
records
of
like
link
local
addresses
or
things
like
that.
L
Those
you
could
imagine
figuring
out
that
they're
wrong,
but
some
of
them
have
quarter
records
that
look
fine,
but
actually
lead
to
absolutely
nowhere.
My
favorite
one
I
forget
for
which
website
it
was
someone
reported
that
it
didn't
work
and
what
they
did
is
for
the
quad,
a
record.
You
had
the
v6
prefix
and,
let's
say
their
ipv4
address
was
1.2.3.4.
L
They
had
the
v6
one
and
ended
with
1
:
2
:
3
:
4,
which
is
not
32
bits.
That's
64,
someone
just
typed
in
the
same
thing
and
replaced
the
dots
with
colons
turns
out.
That's
not
how
these
six
works
now
much
more
complicated,
but
just
a
little
bit
and
yeah
any
time
you
would
try
to
send
pings
or
TCP
sends
or
whatever
that
address
go
nowhere,
because
it
was
completely
bogus,
but
from
the
host.
You
can't
really
guess
that.
So
what
we
do
in
this
case
is
one
we're
on
a
v6
only
Network.
L
L
A
third
case
is
even
more
subtle
is
when
you
have
a
VPN
that
decides
it
wants
to
tunnel
your
DNS
traffic,
that's
actually
very
common.
A
bunch
of
enterprises
have
their
network
set
up
apples.
This
way,
for
example,
we're
a
bunch
of
websites
something.com
alright
only
accessible
through
the
VPN.
So
if
you
try
to
resolve
that
on
the
public
dns,
it
won't
work,
but
that's
if
they're,
not
all
under
the
same
about
some
of
the
like
developer.com
is
accessible
worldwide,
but
not
all
of
them
are
and
also
to
protect
users,
privacy.
L
They
want
to
tunnel
all
the
DNS
traffic
through
the
VPN.
However,
it's
a
split
tunnel
VPN,
meaning
that
it
only
routes,
some
portion
of
the
internet,
only
the
internal
network.
So
what
ends
up
happening
generally
on
the
dual-stack
network?
Is
you
send
all
your
do
it
DNS
queries
to
the
VPN
server
if
it's
internal
or
otherwise
it
gives
you
the
right
reply
and
then
you
can
connect
to
that.
The
problem
is
now.
L
Imagine
you
on
a
v6,
only
cellular
network,
which,
in
case
of
our
customers
using
t-mobile,
is
the
case
and
you're
trying
to
access
a
v4
on
your
website.
So
you're
send
your
DNS
query
to
your
VPN
DNS
and
then
they
quarry
up
the
server
and
say:
oh
well,
there's
no
V's
what
a
record
and
here's
an
a
record
and
then
you
look
at
it.
You
go.
Oh
I
have
an
a
record
and
I
don't
have
a
before
dress
drop
it
on
the
floor.
L
What
do
I
do
because
the
DNS
resolver
for
the
cellular
interface,
it
doesn't
know
about
your
internal
VPN
queries,
so
it
can't
ask
for
those,
but
the
VPN
resolver
doesn't
know
what
the
v6
that's
explorer.
Prefix
on
the
cellular
is
so
you
end
up
having
no
one
actually
has
the
root
of
truth,
far
you're
supposed
to
connect
to
this
address.
So
what
you
have
to
end
up
doing?
Is
you
do
the
a
query
to
the
VPN
you
get
it
and
then
back
to
the
previous
step
above
you
synthesize
it
locally.
L
At
the
end
of
the
day,
it's
not
that
much
work,
because
you
basically
just
plumb
all
these
things
into
the
one
above,
but
it's
like
small
details
that
we
wouldn't
necessarily
hadn't
thought
of
when
these
are
our
sieves
were
initially
written
or
when
we
wrote
our
first
implementation.
It
really
happened
in
operational
issues,
going
why
the
hell
isn't
this
working,
so
we've
added
those
to
the
document
to
help
people
who
are
trying
to
implement
this,
not
discover
these
issues
on
their
own
and
quit
points
so
yeah.
L
We
added
a
limitation
section,
because
there
are
three
things
that
happy
eyeballs
do
not
solve
an
it
gives
it
a
lot
of
scope
of
the
document.
First,
one
is
path,
MTU
discovery,
so
that
is
a
real
problem.
We're
not
denying
that.
However,
we
believe
that
that's
best
solved
inside
the
TCP
stack,
because
happy
eyeballs
only
operates
at
the
connection
time
so
since
in
AK,
which
I'm
Mike
quick
aren't
padded,
so
you
actually
don't
notice
any
MTU
problems
between
the
sin
and
the
Cenac
so
happy
about.
Can
we
help
here?
L
L
But
that's
kind
of
the
point.
So
Jordi
has
a
draft
that
is
probably
presenting
later
in
v6
ops
to
say
how
can
we
actually
address
this
problem
and
I
think
that's
an
interesting
solution,
but
it's
marked
as
out
of
scope
for
happy
eyeballs
in
particular,
because
the
whole
point
is
for
users
to
not
have
to
notice
these
operational
issues.
L
C
Geordi
pilot
thanks
for
for
taking
this
work,
I
I
think
it's
ready
for
for
last
call.
Probably,
let's
see
what
what
others
believe
I
I
am
NOT
an
implementer
I
am
NOT
developer
of
stocks
or
operating
systems,
so
I
understood
now
that
my
request
for
including
the
patent
you
solution
is
not
really
a
good
idea
to
mix
which
happy
Abel's.
C
L
So
the
way
our
stack
does
it
is,
it
keeps
track
of
what
size
MSS
it's
been
sending
and
what's
been
act,
and
if
it
realizes
that
at
some
point,
when
it's
got
enough
data
from
the
application
and
sending
fall
like
fourteen
twenty
or
fourteen
more
packets,
that
those
aren't
never
getting
act,
it
actually
has
some
logic
in
the
TCP
stack
to
tile
back
then
an
SS
until
something
starts
flowing
again,
so
we
have
support
there.
It's
completely
is
separate
from
happy
eyeballs
I'm,
not
sure
that's
documented
in
our
90th
document.
C
Sorry
I
am
I
am
not
really
sure
is
documented
in
such
a
way
that
all
the
operating
systems
are
implementing
something
to
sort
it
out.
So
I
am
willing
if
there
is
other
people
interested
in
working
on
that,
and
especially
people
working
on
the
stacks
like
you
to
work
in
a
draft
to
to
to
document
that
and
to
provide
some
things
to
other
operating
system
or
a
stack
developers.
So
that's.
L
L
E
Mirinda
learns
the
clearly
partly
partly
non-technical
question
here.
I
think
this.
This
all
makes
this.
This
all
makes
sense
from
a
technical
perspective.
A
couple
of
non-technical
things
are:
this
is
kind
of
relatively
hard
to
do
so,
if
you're
building
a
hundred
billion
dollar
product
sure
you
do
everything
that
you
can
the
question
is:
what
would
you,
what
should
we
recommend
to
less
sort
of
sophisticated
products
and
I
think
one?
E
One
interesting
thing
is
like
what
like
to
characterize
the
cost
benefit
of
doing
this
kind
of
thing
like
what
is
what
do
you
lose
in
today's
internet?
If
you
don't
do
this,
and
is
that
getting
better
or
worse
is
like
not
really
necessarily
due
to
this
because
again,
this
is
just
if
you
want
to
do
something.
Awesome
go
do
this,
which
is
great
I
I.
Do
wonder
what
what
sort
of
guidance
we
would
want
to
provide?
You
know
at
what
level
does
this
become
important,
and
the
other
side
of
that
is?
L
T
At
direct
pressure,
because
then
you
get
that
in
we've
now
had
hop
I
almost
requite
a
few
years,
and
did
we
get
any
feedback
from
like
web
server?
Operators
to
say
was
this
ever
a
problem
like?
Did
it
increase
their
load
aloft
and
so
I
mean
now
we're
increasing
the
time
person?
It
shouldn't
be
a
problem
anymore,
but
I
don't
know:
do
we
do
it?
Did
we
ever
get
any
feedback
on
that
or
complaints
or
something
I
haven't
seen
any
particularly
yeah,
so
I
think
that's
like
for
the
room.
L
V
Hi,
my
name
is
Nabil
benomar
from
University
of
McNees
Morocco
and
a
nice
fellow
here.
So
my
question
is
about
your
the
timer
that
you
have
stated
in
this
RFC
draft,
which
is
15
milliseconds,
so
based
on
what
you
have
chosen
this
this
this
timer
exactly
with
this
this
this
number,
because,
for
example,
for
the
previous
one,
it
was
said,
300
milliseconds,
and
there
was
no
clear
specification
on
based
on
what
they
have
chosen
this
this
value.
L
There
are
two
separate
timers
one
is
when
you
started
a
TCP
connection
by
that
I
mean
sent
a
TCP
syn.
How
long
do
you
wait
until
sending
a
note
the
next
one
to
the
other
address
if
you
haven't
heard
back,
so
that's
the
one
that's
based
on
our
TT
that
was
initially
300
milliseconds
in
the
initial
document
that
was
recommended
hundred
fifty.
So
that's
one
timer,
the
other
one
is
the
DNS
timer,
which
is
when
you
get
the
a
record
in
50
milliseconds.
L
Oh
excuse
me
we're
determined
empirically
from
data
we
have
from
billions
of
devices
in
the
field.
We
notice
that
50
milliseconds
was
a
good
sweet
spot
that
he
covered,
like
the
99th
percentile
of
cases
where
the
v6
just
got
reordered
and
came
right
after
it
and
was
still
small
enough
that
the
user
wouldn't
notice.
So
that's
how
this
was
determined
did.
V
P
F
P
About
the
status
I
think
proposed
standard,
it's
fine,
I
think
the
the
goal
in
having
a
standard
is,
of
course,
to
provide
flexibility
right.
We
had
happy
eyeballs
now
we
want
to
have
the
eyeballs
be.
Why?
Because
you
found
things
that
all
of
us
found
things
that
are
learnings
after
happy,
eyeballs
and
so
just
like,
when
we
did
3484
and
67
24
there's
opportunities
for
innovation.
P
Okay,
then,
as
long
as
it's
not
too
constrained,
so
that
was
the
discussion
around
6555,
which
was
why
it
was
recast
from
an
exact
algorithm
in
a
set
of
requirements
to
provide
that
flexibility,
and
that's
why
you
can
still
claim
that
yes,
you're
confirming
to
6555,
involve
the
party
ship,
happy,
eyeballs,
b2
right,
and
so
it's
retaining
that
that
concept.
That
says
we
want
to
allow
an
innovation
as
we
learn
things
and
still
clean
compliance.
That's
what's
important!
When
going
to
post
energy
Thanks.