►
From YouTube: IETF97-V6OPS-20161114-1330
Description
V6OPS meeting session at IETF97
2016/11/14 1330
B
D
B
D
C
B
So,
okay
I'm
not
seeing
any
way
any
more
people
coming
in
now,
I'm
seeing
people
coming
in
I
believe
this
is
the
ipv6
operations
working
group
ipv6
ops.
These
are
my
co-chairs.
Fri
Baker,
Ron,
bonica,
Ronald
E
joining
us
in
a
little
while,
unfortunately,
Ron
as
you
know,
was
just
added
as
a
co-chair
and
his
other
working
group
happens
to
be
meeting
at
the
same
time.
So
he's
a
you
know,
we're
very
happy
to
have
him
so
standing
in
for
co-chairs
is
our
area
director,
Julie,
egli,
Thank,
You,
Joel,
no.
A
B
Some
administrivia
minutes
your
name
here,
so
that
was
Eric
vinca.
Thank
you,
Jabbar
Michael
Abramson,
thank
you
and
I.
Do
have
the
links
up
here
and
I
sent
them
to
the
mailing
list,
because
some
links
to
meeting
materials
were
not
working
as
well
as
others,
so
I
hope
that
everybody
who's
looking
for
meeting
materials
has
found
them.
B
We
have
a
note
well
I,
like
to
split
with
since
we're
meeting
on
Monday
I
like
to
spend
an
extra
minute
talking
about.
What's
in
the
note
well,
this
says
any
contribution
that
you
make
to
at
the
microphone
on
a
mailing
list
is
actually
a
public
contribution.
You
can't
go
back
and
later
and
say
no,
no,
no!
That
wasn't
meant
for
her
for
IETF
consumption.
B
B
Yes,
there,
you
are
no
to
talk
about
design,
principles,
design
choices,
Phillips,
going
to
talk
about
design
choices,
Phillip
for
you,
the
room
to
talk
about
design
choices
and,
of
course,
I'm
going
to
ask
that
you
stay
in
the
pink
box
so
that
our
remote
participants
can
see
you
and
you're.
Welcome
to
you're
certainly
allowed
to
do
that.
Yes,.
F
F
Thing
doesn't
need
to
be
working,
yes,
okay,
hi
I'm,
Philip
Matthews,
and
this
is
joint
work
with
Victor
who's
over
there
he's
better
present
shortly
after
me,
in
a
related
topic.
So
this
says
actually
is
the
dash
11
version
of
this
document.
We
actually
published
the
dash
12
version
this
morning
with
the
one
change
which
I'll
talk
about
in
in
a
minute
and
a
few
little
things
so
next
slide.
F
So
here
is
the
agenda
I'm
only
playing
to
talk
for
maybe
10
minutes
max,
so
that
we
have
time
for
discussion,
and
otherwise
we
can
save
things
for
other
things,
so
am
I
going
to
go.
Sort
of
one
fly
quickly
remind
you
of
what
this
document
is.
This
document
has
been
around
for
a
long
time,
so
I
don't
feel
bad
if
you
have
forgotten
it
and
we
are
very
much
hoping
to
put
out
it
put
it
out
of
its
misery
shortly.
F
The
last
time
we
actually
presented
this
document
I
was
in
Yokohama
a
whole
year
ago,
because
I
then
went
AWOL
for
most
of
this
year
were
on
another
project
and
it
was
only
due
to
victor
over
there
and
kindly
sort
of,
but
repeatedly
prompting
me
saying
we
should
work
on
the
document.
We
really
should
work
on
the
document
that
we're
here
at
all
so
a
little
kudos
to
rip
to
Victor
for
making
it
happen
anyway.
So
we
are
going
to
talk
about
their.
We
modified
the
document
scope
a
little
bit
or
clarified.
F
I
guess
that's
actually
clarified
the
document
scope
a
little
bit.
We
made
a
number
of
changes
and
I'll
go
through
this
and
there
are
the
changes
in
the
igp
section,
just
adding
a
bunch
of
detail.
We
tweaked
the
bgb
section
and
we
did
a
complete
rewrite
of
the
addressing
section
because
we
got
hell
for
that
in
yokohama.
F
So,
okay
with
that
next
slide,
okay,
so
here's
the
one
side.
So
what
is
this
document
for
all
of
you
who
have
forgotten?
It
describes
routing
related
design
choices
in
v6
only
or
dual
stack
networks,
and
these
are,
if
you
will
sort
of
their
sort
of
lower
level
than
most
of
the
higher
level.
Here
is
how
you
do
v6
deployments
that
the
working
group
has
previously
published,
though
it
has
about
trying
078
of
those
over
the
past
number
of
years.
F
So
this
is
a
little
bit
lower
level
than
that,
and
it
assume
so
it's
running
late,
and
only
first
of
all,
it
is
not
a
DNS.
It
is
not
dhcp,
it
is
not
and
host
okay,
it
is
Rowdy
related,
and
it
assumes
that
the
reader
has
a
working
knowledge
of
v4
network
design,
and
so
all
they
want
to
do
is
now.
What
is
this
basic
stuff?
How
do
I
do
design
in
this
brand
brave
new
v6
world?
Okay,
this
document
history?
Then
this
talking
is
rand.
F
F
We
last
we're
here
discussing
this
in
yokohama
a
year
ago
and
I
said
then
went
tired
and
Victor
finally
parted
me.
We
got
back
to
this.
We
had
a
dash
ten
at
dash
11
and,
as
of
now
today,
a
dash
12
trying
to
actually
finish
this
document
up.
Okay,
next
slide,
okay
changes,
so
very
early
with
versions
of
this
document
actually
just
said
he
would
talk
about
anything
related
to
v6
design
choices.
That
was
obviously
way
too
big.
F
You
could
write
a
hundred
page
document
or
something
like
that
with
that
type
of
scope,
so
we
Claire
cut
that
one
down
actually
pretty
soon
shortly
it
in
the
introduction.
It
is
said,
routing
related
for
quite
a
while,
but
we
kept
on
having
people
sort
of
overlook
that
portion.
So
this
morning
the
dashed
well
version
that
publishes
now
says
routing
related
in
the
title
as
well:
okay,
that
was
the
probably
the
biggest
single
change
that
went
in
in
the
dash
12
version.
F
Okay,
next
neutral
tone.
So
when
the
document
started,
it
was
always
doing
one
up
there.
Okay,
it
was
saying
here's
a
choice
here.
Your
options
here
are
some
facts
about
these
options.
Here
some
pros
and
cons
as
we
worked
away
on
this
document,
a
number
of
sections
started
slipping
to
be
more
number
two:
okay,
where
they
didn't
present
pros
and
cons.
They
just
said:
do
it
this
way?
One
of
the
comments
we
got
in
Yokohama
was
that
that
was
not
good.
We
agreed
with
them
so
part
of
the
rewrite
that
we
did.
F
This
fall
was
to
go
back
through
clean
up
the
document
and
just
do
one
everywhere.
Basically,
the
idea
is
mr..
Mrs.
network
designer
here
are
your
choices.
Here
are
your
options
here
are
some
facts
that
you
want
to
know,
maybe
a
bit
of
pros
and
cons.
Now
you
make
your
own
decision.
Okay,
what
way
you
want
to
go?
F
Okay,
next,
okay,
so
I
GP
section.
So
when
this
section
was
originally
published,
it
focused
mostly
around
a
survey
that
Victor
and
I
did
about
two
years
ago
now
of
operators
on
what
I
GPS
they
actually
ran
in
production
networks.
Okay,
that
was
the
primary
focus
of
this.
One
of
the
feedback
we
got
was.
It
would
be
good
to
have
a
little
bit
more
to
back
that
up.
So
the
now
in
the
new
version,
has
a
lot
more
text
about.
Okay,
here
are
your
choices.
F
Here
are
some
pros
and
cons
about
your
choices
and
by
the
way
here
are
as
sort
of
supplemental
information
heroes
what
people
actually
run
today
in
their
network.
Okay
and
another
comment
we
got-
somebody
pointed
out
the
mailing
list
that
we
were
missing.
One
of
the
options
you
can
actually
ruse
ospfv3
to
route,
both
v4
and
v6.
So
that's
now,
there's
a
table
in
that
section
and
that
we
now
added
that
we
actually
thought
it
was
there
and
you
just
point
out:
we've
actually
forgotten
about
next
bgp
section,
not
really
very
much
changes.
F
They
are
just
a
little
bit
going
through
cleaning
things
up,
making
little
tweaks
here
and
there
next
address
section.
So
this
is
the
big
change.
So
if
those
people
who
actually
remember
youth
the
Oklahoma
discussion
for
a
year
ago-
and
you
guys
are
probably
are
forgotten
about
it-
this
is
what
everybody
complained
about
this
section
and
we
got
tell
for
this
section.
So
we
did
a
complete
rewrite.
Okay,
we
removed
all
the
ipv4
stuff
from
it.
It
talks
now
only
about
b6.
It
basically
starts
and
start
says.
F
If
you
look
at
a
v6
interface,
it
must
have
a
link
local
address
on
it.
It
may
have
one
or
more
other
addresses
which
we
sort
of
generic
cool
off
there
and
culture
of
multihop
addresses
okay.
So
what
do
you
wish
to
go?
There
are
three
choices
that
you
can
or
no
three
type
that
you
can
choose
from
and
where
do
you
want
to
use
them?
Do
you
want
to
use
them
on
your
loop
backs?
Do
you
want
to
use
them
on
your
links?
F
Okay,
and
by
the
way
you
know
it
well,
but
your
choice
probably
depends
on
how
you
run
your
network.
Are
you
one
of
those
classic
ISPs
that
carry
your
internet
traffic,
hop
by
hop
through
court
or
you'll
sort
of
more
recent
variety
that
carries
everything
inside
a
layer,
3
VPN?
That
will
determine
a
little
bit,
which
way
you
go
next?
F
Ok,
actually,
why
don't?
We
walk
back
for
two
seconds
and
just
remind
everybody,
go
out
there
with
the
school,
remind
everybody
what
I
just
said
it
because
I
went
through
it
really
quickly
and
then
I'll
go
that
last
slide.
So
yeah
we
did
ya
start
right
from
there,
so
we
did
document
scope,
that's
what
their
next
I
should
have
put
this
slide
in.
I
did
this
very
last
there
we
did
neutral
tone
through
well,
we
did
this
change
the
igp
section,
de-emphasizing
the
survey
and
adding
a
whole
bunch
of
basic
facts
about
it.
F
We
tweaked
the
bgp
section
and
we
completely
rewrote
the
addressing
section,
because
people
really
hated
the
previous
version
so
and
at
this
point,
I'm
I
should
help.
You
turn
around
and
dress
the
the
chairs.
This
is
our
thoughts
about
how
we
should
proceed.
We
think
it
is
done.
We
think
it
is
ready
to
go
I.
It
would
be
good
to
get
some
comets.
There
was
two
reviewers
who
reviewed
it
last
time.
One
of
them
was
so
kind
to
email.
Me,
a
second
review
just
a
few
minutes
ago.
F
G
G
F
G
I
F
I
F
Okay,
so
we
are
definitely
going
to
blow
a
blower
added
address
tables
out
of
the
water.
Okay,
glad
you
guys
as
I
work
for
a
vendor.
Actually,
both
the
Victor
and
I
now
work
for
vendors.
So
all
you
operators,
we
are
happy
to
have
this
be
true,
because
you
could
buy
simply
buy
lots
for
product
from
us.
We're
very
happy
go.
J
Ahead,
luckily,
I
think
the
section
on
addressing
is
almost
perfect
because
in
the
first
sentence
says
it
doesn't
talk
about
hosts
and
when
you're,
when
you're
use
it.
When
you're
talking
about
addressing
assigned
to
reuters,
you
can
use
bogan
space
for
like
her
and
you
can
use
whatever
you
want.
You
can
use
the
root
server.
Ip
addresses,
that's
my
favorite,
that's
my
favorite
is
are
signs.
That
being
said,
I
agree
with
it
was
with
tim,
I
don't
like
seeing
NPT
66
there.
It's
not
clear
to
me
why
you
would
use
NPT
66.
J
It's
the
only
thing
that
you're
talking
about
numbering
is
your
Reuters,
but
you
know
so
what
I
would
suggest
is
that
you
would
say:
ula
is
not
covered
day,
so
NPT
66
is
not
covered
here
and
the
drawbacks
of
you
lay
are
as
follows,
and
because
we're
only
talking
about
Reuters
here
it
doesn't
matter
tonight.
So,
like
I
said
you
can
use
my
favorite.
My
favorite
restaurant
for
the
Reuters
is
the
global
root
server
IP
addresses.
J
K
C
K
F
B
L
There
you
go,
she
does
the
name
the
on
the
pipe
thing
you
know,
I
mean
this
is
my
personal
opinion
here
is
I.
Think
in
the
draft.
We
should
still
note
that
it's
not
trivial,
there's
a
you
know
if
we
suddenly
in
the
v4
world,
which
is
what
a
lot
of
people
had
before
they
had
a
v6
you
could
you
know
you
just
just
saying
I'm
going
to
get
P
I
space,
there's
things
that
operator
has
to
do.
L
F
G
H
G
A
G
A
B
I'm
going
to
suggest
well
I'm
gonna
suggest.
First
of
all
that
sounds
like
we
have
one
or
two
sentences
that
we're
discussing
right
now
and
that
if
the
four
or
five
people
who
have
comments
on
those
one
or
two
sentences
would
send
suggested
sentences
to
the
list,
we
could
probably
move
through
that
fairly
quickly
and
agree
on
and
do
the
word
smithing
on
the
mailing
list,
which
is
a
great
place
to
do
it
because
everybody
can
see
the
words
we're
talking
about.
B
Okay,
good
can
I
ask
before
we
get
on
to
path
forward
and
the
mic
is
still
open.
We've
got
plenty
of
time.
Can
I
ask
how
many
people
have
read
the
10,
11
or
12
version
of
this
documents.
Raise
your
hand,
please
all
right.
So
that's
that's
a
pretty
good
number,
okay,
so
and
I'm
here
and
actually
more
than
half
of
those
who've
actually
commented.
The
Michael
on
the
document
said
it's
pretty
close,
so
my
suggestion
will
be
that
we
have
those
couple
of
minor
tweak
conversations
on
the
list.
B
If
you
guys
can
can
can
watch
those
you
know
figure
out.
The
consensus
looks
like
and
spin
another
version
in
a
couple
of
weeks,
where
I
think
we
probably
already
44
working
group
last
call
unless
somebody
disagrees
that
approach
I'm
going
to
swing
the
gavel
and
say
that's
what
we
got
to
do
excellent,
I
love
it
when
we
move
forward.
L
Is
coming
here
come
on
right
now,
so
John,
Wazowski,
colleen,
awesome
comcast
is
a
co-worker
of
mine.
We've
done
a
lot
of
this
work
together,
and
it
just
so
happens
that
she's
here
in
Seoul,
so
I
invited
her
to
the
liberty
of
inviting
her
up
so
that
we
can
kindly
jointly
be
here
to
walk
through
this
very
brief
update,
I
sent
slides,
but
to
do
yeah
they're,
pretty
brief.
What
kind
of
you
at
least
try
to
bring
them
up?
We'll
talk
to
you
briefly
about
these,
so
is
gone
through
here.
L
So
one
of
the
things
that
we
are
there's
been
through,
so
one
of
the
things
that
we
are
working
on
guns
and
I
have
been
a
bit
remiss
in
kind
of
processing.
Some
of
the
updates
that
we
have
with
you
guys
you're
not
going
to
sit
down
tomorrow,
probably
Colleen,
and
we're
try
to
submit
a
new
version
this
thing,
so
we
can
close
this
out.
The
main
reason
we
basically
and
the
chair
for
updates
here
is
we
start
to
roll
this
out
a
comcast
we're
about
sixty-five
percent
of
our
Wi-Fi
footprint.
L
Wi-Fi
footprint
has
this
rolled
out
the
other
half.
We
think
we
yesterday
will
be
out
by
say
later
this
year
or
first
part
of
you
know
first
quarter
2017,
so
we're
well
on
our
way.
We
had
a
couple
of
things
that
we
had
to
kind
of
work
through
now,
nothing
tragic
as
relates
to
what
we've
written
in
the
document
more
kind
of
vendor
bugs
that
sort
of
stuff.
L
There
are
some
things
that
were
typically
typically
fall
outside
the
realm
of
ITF
things
that
we
had
to
deal
with
from
an
internal
systems
perspective
things
like
being
able
to
respond
to
you
know,
law
enforcement
agencies
that
sort
of
stuff,
but
other
than
that.
The
only
other
comment
I
think
we
you
know
that
we'd
like
to
make
is
we're
seeing
a
lower
than
normal
expected
you
option
or
usage
of
v6.
We
think
that
there's
some
some
investigation.
We
have
to
go
ahead
and
do
there.
L
So
unless
we
really
don't
need
two
slides,
because
that's
basically
what
it
all
says,
we'll
take
a
few
questions
from
you
guys
see
if
hears
anything
that
you're
curious
about
and
then
the
only
other
piece
to
this
for
those
who've
read.
The
draft
is
there's
two
parts
to
this:
work
that
we're
doing
in
and
Comcast.
L
One
of
them
is
your
ue,
your
user
equipment
and
its
connectivity,
which
is
basically
everything
that
we've
talked
to
you
about
here
and
then
the
other
part
of
this
that
you'll
see
that's
also
documented
in
the
giraffe,
is
the
underlay
technology
right,
so
so
the
former
we're
going
to
call
overlay
the
underlay.
You
know
in
this
case,
for
us
we
use
ya,
jari
and
I
think
we're
starting
looking
at
l2tp
right.
L
That's
going
to
be
part.
Two
of
this
project
where
we
convert
the
underlay,
be
v6
only
as
well.
I
think
that's
less
interesting
to
this
crowd
for
the
most
part,
but
it's
still
something
that
we
feel
is
germane
to
be
six
apps
and
and
the
work
that
we
generally
talk
about
here.
So
with
that
I'll
pause
for
any
questions,
comments,
curiosities,
I
think
we,
the
only
other
thing
that
we're
looking
at
doing
is
if
we
can
get
this
draft
submitted
most
of
the
feedback
we've
gotten
so
far,
it
seems
pretty
editorial.
J
Learn
is
clearly
a
couple
of
comments.
You
mentioned
it
less
v6
traffic
than
expected,
I
wonder
if
them.
If
using
l,
equals
0
I
think
some
some
version
of
Apple
it
was
reported
that
they
don't
do
they
don't
reply
to
neighbor
solicitation
sent
from
a
global
address
if
l
equals
0,
and
so
you
might
be
seeing
their
happy
eyeballs
algorithms
to
be
four.
Instead,
you
could
switch
to
using
the
link
local
address
to
do
the
neighbors
field
station.
Then
that
might
work
better
I.
That's
just
an
idea
can't
say
that
we're
not
doing
that,
though.
J
L
J
Than
that
I'm
sure
you're
aware
of
it,
but
you
know
maybe
for
others
to
there's
a
draft
in
going
forward
in
six
men
or
going
to
be
discussed
in
six-man
tomorrow's
it
tomorrow
yeah
about,
because
you
provide
any
unique
prefix
for
host
just
adding
a
bit
to
the
to
the
proof
to
the
RA.
That
says
this
prefix
is
dedicated
to
you
because
it's
already
dedicated
and
then
the
host
can
do
a
lot
of
lots
of
optimizations.
And
so,
if
anyone's
interested
in
that,
you
know
come
to
six
men
read
the
draft.
So
one
comment.
L
On
that
one
part
of
the
reason
why
we
even
wrote
this
to
be
shared
here
in
v6
offices,
because
we've
got
some
feedback
from
other
part,
other
people,
the
community
say
hey.
You
know
this
looks
like
it's
interesting
and
useful
since
then,
we've
also
started
looking
at
it
using
another
contact
to
be
on
Wi-Fi
right,
so
Colleen
or
collie
and
I
do
together
is
really
kind
of
me
and
Wi-Fi
related,
but
we're
looking
at
it.
L
In
many
other
contacts
you
know
the
day,
Center
would
have
you
I
know,
there's
some
Facebook
folks
here
that
I've
had
the
conversations
with
or
at
least
kind
of
indirectly.
So
that's
you
know:
FYI
full
disclosure,
so
we
you
know,
we
have
read
it
yet
so,
but
I
will
and
I'll
be
prepared.
To
kind
of
you
know
provide
some
comments,
but
we
like
the
direction,
is
going
as
well
thanks.
M
B
That
sounds
I
agree
with
what
you
described.
It
sounds
like
it's,
it's
pretty
mature
and
we'll
give
it
a
little.
You
know
a
little
longer
or
a
feedback
and
then
do
a
working
group
last
call
unless
anybody
further
has
comments
on
that,
because
this
is
also
has
seemed
like
its
head
fairly
strong
consensus
over
it's
its
life.
B
K
K
B
K
You
ok
so
just
for
those
who
did
not
attend
this
meeting
class
time
just
slide
from
our
presentation
now
I
made
on
a
TFR
96.
So
the
problem
statement
we'd
like
to
solve
problem,
which
has
already
been
mentioned
today
about
how
can
we
do
multihoming,
an
enterprise
network
using
provider
address
space,
yeah
I
was
out
to
get
in
your
own
address
space
or
runyon
bgp
who's,
your
isp,
because
in
many
cases
had
just
not
the
good
choice,
and
there
are
two
part
of
the
problem.
K
First,
how
can
you
send
precarious
particular
source
address
to
the
right
is
p,
and
this
is
routing
part
of
the
draft
which
talks
about
source
address,
dependent
routing
and
then
how
can
you
make
host
to
choose
the
right
address?
Whatever
right
means
in
particular
case,
so
this
packet
could
be
delivered
and
yeah
yeah
we
as
humans.
K
There
are
providers
out
there
who
do
implement,
bcp
search
it,
and
indeed
we
do
not
want
to
talk
about
not
oh
and
and
apparently
there
is
no
proper,
where
you
couldn't
do
it
currently,
without
where
else
nice,
dear
hugs,
so-
and
it
looks
like
people
out
there
actually
already
started
doing
some,
not
pity
and
so
on,
because
there
is
no
as
a
proper
solution
for
this
problem.
So
there
is
a
link
to
the
right
place,
slides
from
the
last
idea,
where
some
nice
pictures
illustrating
what
I'm
talking
about.
K
So,
if
you
do
not
want
to
read
the
draft,
you
can
just
look
at
the
slides
and
next
slide.
Please
so
not
many
changes,
I
didn't
dance
or
clarified
some
sections
about
default.
Address
selection
because
basically,
the
whole
a
trick
we
are
proposing
is
relying
on
Muslim
055
for
default,
address
selection,
algorithm
and
then
are
aware
that
a
section
to
discuss
a
problem
of
selecting
dinners
because
selecting
the
right
address.
K
It's
just
a
part
of
the
problem
and
we
can
do
some
interesting
things
using
default
text,
selection
and
slug,
as
described
in
the
draft,
but
apparently
host
also
might
need
to
properly
select
other
configuration
parameters
like
dienes
and
search
list,
and
it
is
actually
maybe
even
more
interesting
than
selection
source
address,
and
I
will
talk
about
in
a
second
and
janna.
Some
references
have
been
added
to
the
document,
so
next
slide.
Please
yeah
and
I.
K
So
it-
and
we
tried
in
the
draft
to
cover
as
many
possible
use
cases
not
just
to
ice
piece
when
you
can
use
either
both
of
them,
one
of
them
as
a
primary
and
secondary
backup,
but
also
various
three
key
use
cases
when
there
are
walled
gardens
and
is
one
of
the
ISP,
my
provide
some
special
services
and
soul.
However,
it
looks
like
one
of
the
few
most
common
use
cases
could
be
easily
addressed
without
even
relying
on
all
55.
K
It
could
be
done
even
today,
with
some
help
from
router
vendors,
so
I'm
still
going
definitely
before
next
ATF
to
fork
a
separate
draft
from
this
one
to
cover
most
common
use
cases
not
solving
cold
problem.
It's
not
a
silver
bullet,
but
just
they
describe
a
most
useful
scenario
and
next
slide,
please
yeah
so
just
to
describe
what's
going
on.
So
this
draft
actually
has
two
big
section.
K
A
section
Swan
is
mostly
talking
about
routing
quad,
about
creative,
about
Eugene
source
address
dependent
routing,
so
how
routers
are
going
to
forward
packets,
I
based
on
the
source,
address,
I'm,
I,
created,
scoped,
forwarding
tables,
and
second,
a
section
for
Chile
I
was
a
draft,
is
mostly
talking
about
a
source
address
selection
on
a
host
and
how
cost
could
interact
with
the
first
opera
or
thurs.
The
first
hop
routers
could
influence
source
address
selection
on
a
host
based
on
the
current
routing
state
of
the
network.
K
So
we
actually
thinking
about
calling
for
adoption
for
the
current
graft
and
routed
working
group,
and
indeed
we
need
a
feedback
from
v6
ops
on
especially
on
the
section
4
of
the
draft
and
the
second
draft
which
I'm
going
to
fork
from
it.
I
will
I
will
present
at
36
jobs,
because
it
does
that
it's
not
going
to
talk
about
routing
rosen
palette
will
mostly
host
default.
Address.
Selection
and
interaction
is
first
hop,
router,
so
stay
tuned
for
the
next
ATF
and
our
next
slide.
Please
actually
next
slide
so
the
tricky
part.
K
So,
obviously,
if
you
have
more
than
one
high-speed
quite
possible,
unless
I
spin
lazy
and
just
sent
you,
google
dns
dennis
error,
I
hosp
might
provide
its
own
set
of
I
dns
our
servers,
IP
and
even
search
list.
Just
just
sending
that
information
to
host
is
relatively
easy
right,
because
the
whole
draft
is
basically
talking
about.
How
can
we
lock
to
configure
host
and
influence
address
selection
of
a
cost?
So
we
can
use
our
DNS
s
to
do
this
and
it's
actually
possible
to
also
duplicate
the
info
dinners
information
from
one
of
the
ISP.
K
If
connectivity
to
the
PSP
is
lost,
so
further
scenario
is
a
reasonably
straightforward.
Next
slide
how
yeah
something
like
this
so
as
I
discussed
in
the
draft,
if
scoped
forwarding
table
for
one
all
right,
I
spirit,
Cobra
DSP,
a
dozen
her
finger
out,
we
don't
have
connectivity
to
zach
is
fee,
so
we
not
just
duplicated
addresses
from
is
PB
block
will
sit
and
duplicate
dns
information
provided,
but
that
is
p
if
needed.
Our
next
slide.
Please,
however,
I
see
at
least
two
problematic
scenarios.
K
So
if
host
has
to
set
of
dns
servers,
it
will
probably
pick
up
just
one
of
those
dns
servers
and
random,
and
there
is
no
way
you
can
currently
influence
the
source
selection
for
dns
server.
So
it's
quite
possible
that
packet
to
read,
isp
dns
will
be
sent
from
blue
address
space
and
next
slide.
Please
yeah
and
it
could
go
through
blue
eyes.
K
They
are
playing
to
the
internet
and
mike
might
even
actually
reach
the
daily
server,
but
we
do
not
know
if
the
if
the
host
will
get
required
cancer,
because
the
dinner
server
might
be
not
reachable
or
might
not.
Answer
on
my
gif
different
answer,
depending
on
the
source
address,
so
basically
did
a
split
horizon,
so
it's
basically
not
desirable
desire
scenario
and
next
slide.
Please
and
another
problematic
scenarios
again
if
there
are
some
local
namespaces
and
you
basically
could
not
resolve
some
namespaces.
K
If
you
ask
a
dinner
set
of
one
isp,
particular
namespace,
which
only
could
be
resolved
through
second
tiles
and
the
indeed
host
will
just
get
an
X
domain
from
name
server,
it
would
not
even
try
to
ask
the
next
one
looks
like
please
yeah,
basically,
samsonite
also
hostess
pick
him
up
the
first
dinner
server
and
the
least
ask
dinner
server
for
some
special,
a
name
from
is
pp,
namespace
get
an
X
domain
and
it
will
be
resulted.
Communication
failure
next
slide,
please
so,
ideally
an
ideal
world.
K
It
would
be
nice
if
host
could
somehow
knows
widget
in
a
server
to
ask
for
which
lane,
but
I
don't
think
it's
actually
possible
now
I
in
genetics
scenario.
So
what
I'm
thinking
about
is
probably
we
just
need
to
kind
of
say:
okay,
we
could
not
solve
all
possible
insane
solaris,
you
might
see
in
the
real
life.
So
probably
a
recommendation
should
be.
K
If
you
do
have
such
complex
scenario
in
your
network,
it
probably
makes
sense
to
run
your
DNS
server
within
the
network
and
let
the
inner
server
to
solve
all
those
problems
and
just
provide
a
local
dns
server
which
is
located
within
the
network
two
hosts
and
do
not
try
to
make
host
to
make
all
those
complex
decisions.
I
probably
update
the
text
of
the
draft
that
will
bend
the
version
02
and
the
next
slide
is
actually
questions.
Comments,
suggestions.
F
So
Philip
Matthews
nokia,
I'm
wondering
what
about
the
case
where
the
ISPs
that
you
know
the
two
dns
service
in
the
ice
piece
will
answer
differently
to
the
same
query.
You
know
there's
a
number
of
cases
there,
and
so
you
know
if
you
get,
if
you
ask
one
and
you
get
an
answer,
you
have
to
send
a
packet
that
way
to
the
ISP
and
if
you
get,
if
you
actually
ask
the
other
one,
you
need
to
send
the
packet
that
way
instead
and
I'm
not
sure
even
running
a
recursive
name.
K
F
K
Is
funny
I
actually
think
you
will
have
the
same
problem
in
before
right?
You
potentially
can,
if,
even
if
you
use
not
right,
you
ascend
the
packet
to
DNS
or
blue
genus.
Okay,
let
me
use
my
terminology.
Ison,
like
it
to
blue
dns,
get
an
answer,
but
actual
data
packet
to
a
server
going
to
read
is
P
because
they
either
the
company's
doing
load,
balancing
or
it's
just
our
out
in
policy
yeah.
So
I,
don't
think
this
problem
could
be
completely
solved.
Oh
at
least
I
have
no
ideas
how
to
prevent
all
possible.
F
J
J
A
draft
somewhere
in
six
men
may
be
to
actually
provide
ways
of
doing
this.
We,
the
myth
working
group,
was
shut
down,
but
there's
no
they're
still
interested
in
doing
this
work
and
I
think
we
can
expect
that
this
eventually
will
become
part
of
operating
systems
right
because
because
operating
systems
already
have,
they
already
have
to
do
this
on
a
per
network
basis
right
that
was
sold
years
ago,
and
so
it's
a
matter
of
communicating
the
bits
of
information
correctly.
K
What
we're
trying
to
do
because
I
personally
feel
scenarios
when
you
have
a
small
Network,
it's
part
of
enterprise
network,
but
it's
small
vacation
somewhere
and
I
have
10
people
seated
right
and
yeah
and
I
tended
resolver
right
there.
It's
not
always
a
good
option,
but
again
I
think
it
depends
on
the
scenario.
If
you
just
chew
eyes,
feast
for
just
for
internet
access,
we
don't
need
to
dissolve
it.
We
just
used
our
DNS
s
and
everything
works.
K
If
we
do
not
have
if
you
have
something
more
complex
than
most
likely
yeah
it's
what
I
will
go
into
putting
the
draft
yeah
if
it's
something
more
complex
and
just
to
internet
applix,
resolver
will
be
best
option
currently
until
our
bright
future,
which
is
hasn't
been
evenly
distributed.
Here.
Finally
comes
yeah.
M
Alright,
so
it's
basically,
it
can
be
made
to
work
like
this
for
easy
cases,
but
not
really
for
complicated
ones.
I
have
a
different
question:
can
you
go
back
to
the
slide
with
the
draft
split
up
beginning
way
way
earlier
that
beckley
at
this
one
I,
don't
understand
why
the
split
is
where
it
is.
To
be
honest,
why
is
the
source
address
stuff
split
apart
in
the
middle
and
we
have
to
select
source
address
selection
in
the
routing
area,
draft
amateur.
K
The
current
draft
is
kind
of
genetic
right,
we're
not
trying
to
solve
just
a
problem
of
who
to
are
pleased.
You
try
to
talk
about
various
titles
like
car
wall
garden,
so
on
and
so
far
it
doesn't
look
like.
We
have
a
easy
way
to
solve
that
problem
without
relying
on
the
rule,
55
and
all
those
things
related
to
do
that,
and
but
we
probably
still
would
like
to
have
some
discussion
on
this
topic
and
have
some
solution
are
providing.
You
can
use
your
own
55.
K
So
this
is
the
current
draft
right
and
because
it's
called
with
this
about
religion,
we're
thinking
about
getting
the
top
10
right,
important
group,
but
a
draft
lorenza
suggest
last
time
is
just
covered
in
one
particular.
But
most
common
use
case
has
nothing
to
do
with
routing,
so
it
will
come
to
v6
ops,
yeah,
okay,
is
it
yeah?
I
think
I.
K
B
So
I'm
going
to
agree
with
that,
so
you
you're
looking
for
feedback
you've
had
a
little
bit.
That
sounds
sounds
like
it's
usefully
we're
not
looking
to
adopt
this
document.
It's
informational
for
this
working
group,
because
this
one
is,
is
we're
looking
for
a
running
working
group,
but
we
hope
to
see
you
again
later
with
the
new
draft
yeah.
K
Yeah
well
looking
for
feedback.
I
know
it's
kind
of
big
request
to
ask
people
to
read
45
pages
draft,
but
you
can
go
to
section
4
if
you
want
and
start
from
there.
As
I
said
last
time,
yeah
so
I
said:
I
posted
it
to
the
mailing
list
at
the
beginning
of
november.
So
here
please
feedback
is
highly
appreciated.
B
B
N
N
I
did
since
the
last
ITF
meeting
the
controversy
during
the
last
meeting
was
the
prefix
itself,
/
16,
that
it
was
just
too
large,
so
I
think
we
agree
that
it
got
reduced
to
our
/
48,
which
has
the
added
side
benefit
that
it
does
not
encompassed
the
prefix
from
RFC
60-52,
which
kind
of
makes
things
so
much
easier
since
now.
This
is
completely
distinct
and
does
not
really
relate
to
the
60-52
prefix
arrow
and
well.
N
N
Don't
think
that
we
should
make
more
adjustments
there
other
than
that
other
the
section
of
about
checksum
neutrality
per
request
fixed
up
the
eye
on
a
consideration
section
so
that
that
has
the
proper
format
other
than
that
I
got
some
various
feedback
on
how
to
mete
out
the
text.
There
add
some
references,
some
editorial
stuff
I
was
intending
to
update
the
draft
that
day,
you
have
got
in
the
vase.
I
didn't
make
the
submission
deadline,
so,
but
that's
just
a
matter
of
getting
that,
though
last
slide,
please.
N
Think
at
this
point
it's
we
really
need
to
decide
if
this
is
something
that
we
should
do
or
not,
and
if,
if
we
should
go
proceed
with
this
and
I
think
it
should
be
a
rather
quick
journey
through
the
through
the
working
group
and
last
call
and
so
on,
because
I
mean
if
we
agree
that
reserving
a
pre,
a
flash
48
prefix
for
translation
is
okay
them.
That's
basically
everything
this
draft
us,
it
should
be,
should
be
a
non-controversial.
N
B
Was
less
than
an
hour
that
was
impressive,
so
we
had
a
lot
of
conversation
at
the
last
meeting
about
this
document
and
it
was.
It
was
not
clear
to
me
then
whether
we
should
allocate
a
prefix
or
if
the
conversation
lead
more
against
what
size
prefix.
So
that
has
so
one
of
those
questions
has
been.
We
has
been
respect.
Aureus
responded
to
it.
I'm
we
need
to
know.
Is
this
something
that
we
think
ought
to
do
and
are
we
there.
J
Rancic
really
I
am
I,
think
I'm
not
opposed
to
either
way,
but
I
think
if
we,
if
we
do,
if
we
do
say,
if
we
reserve
a
48
for
NSPS,
we
should
provide
some
guidance
as
to
when
you
would
use
your
own
address
space
and
when
you
would
use
a
cig
for
ff9,
be
something
right,
because
previously
you
could
use
NSPS
right,
you
just
allocate
them
and
so
I
think.
Maybe
maybe
it
wasn't
a
previous
version
of
rough.
J
I
just
did
skimmed
it
again
and
I
didn't
see
it,
but
we
should
provide
guidance
as
to
when
do
you
use
this,
and
when
do
you
not
because
people
might
assume
that
that's
what
you
have
to
do,
but
it's
it
does
you
know
it's
not
necessarily
the
best
option
and
the
one
thing
that
you
say
in
your
draft
is
implementations
must
not
assume
anything
about
these
addresses.
Well,
we
know
how
that's
not
all
right,
so
we
we,
we
should
think
about
what
guidance
we
want
to
give
at
least
a
point,
though,
into
the
right
direction.
N
Yeah
so
and
I'm
not
sure
if
I
actually
put
that
into
the
draft
in
very
clear
terms,
but
the
idea
is
that
you
to
have
a
prefix,
that's
very
distinct
from
your
own
address
space
so
that
it
does
not.
You
know,
share
the
properties
of
your
own
other
space
with
regards
to
you
know,
having
full
access
to
your
mail
servers,
free
laying
or
your
DNS
servers
for
resolving
and
so
on,
so
that
the
addresses
that
basically
represent
the
ipv4
internet
does
not
masquerade
us
a
subset
of
your
own
address
bay.
J
O
N
The
same
thing
you
cannot
know
if
the
even
if
you're,
using
that
64
and
62
algorithm
with
it,
you
can
still
not
know
if
it's
/
64
or
if
it's
a
96,
and
if
so
you
cannot
know
where,
in
the
address
space
the
ipv4
addresses.
So
basically
it's
the
same
as
with
a
with
a
global
unicast
address
right.
You
cannot
know
if
that's
and
I
before
embedded
address
and
if
so,
where
do
I
pee
for
addresses.
N
B
P
Q
B
R
Told
this
is
tarick
Sarah's
and
I
have
a
read
the
RFC
or
the
rough
so
far,
but
I
know
about
the
nat64
and
dns
6490
six
bits
prefix
so
can
I
ask
that
I
have
discussion
with
toe
on
emails
about
this
issue
earlier
two
years
ago,
when
we
were
doing
the
ipv4
ipv6
habit
network
deployment
projects.
Actually
my
question:
is
there
increasing
the
host
ID
portion?
Can
we
solve
the
multicast
salut
issues
in
translation.
N
I,
don't
really
know
how
to
answer
that
the
RFS,
if
this
is
being
used
in
RFC
6052
context
them
them
them.
It's
basically
a
matter
of
embedding
a
night
before
address
in
the
956
address,
or
vice
versa.
So
if
that's
a
multicast
address
or
unspecified
addressed
or
whatever
it's
just,
you
know
putting
bits
in
a
larger
sequence
or
bits
or
extracting
bits
from
a
larger
sequence
of
bits,
but
operationally.
N
If
you
can
use
this
to
make
multicast
work,
there's
no
provisions
for
that
or
any
feature
that
would
make
strong
ipv4
to
ipv6
translation
of
multicast
traffic
work.
So
I
guess
it
depends
on
the
technology
if
you
have
a
technology
that
allows
that
to
happen,
and
it
needs
a
translation,
prefixed
and
I'm
sure
that
you
can
use
this
prefix
as
any
other
prefix
for
that
solution.
But
that's
not
really
I'm
a
goal
of
this
draft
to
to
make
multicasts
work
so
to
speak.
B
R
Basically,
ipv6
has
so
many
multicast
traffic,
so
the
translation
should
be
focusing
the
multicast
traffic
as
well
in
net
64.
When
the
64
cullen,
FFM
9v,
Colin,
Colin,
/
96
prefix
were
using
the
it
was
not
supporting
the
multi-class
issue
so
that
that
I
I
question
this
in
that,
in
that
perspective,
actually
it's
the
two
years
back.
I
hope
tour.
Remember
my
emails
because
we
haven't
exchanged
email
after
the
debt
project
when
we
concluded
so
hopefully,
unless
I
implemented
to
your
question,
I
can
have
comment
on
that.
I
would.
B
N
N
F
Full
of
Matthew's
so
I
just
scanned
this
draft
and
it's
been
a
few
years
with
all
the
stuff
with
well-known
prefix,
why
my
memory
is
a
little
bit
poor
and
all
this
you're
pulling
a
slash
48
with
colon
1
there
and
the
well-known
prefix
has
a
colon
0,
but
is
only
a
96.
What's
what's
happening
with
the
rest
of
the
colon
0
/
48
I
guess
is
the
whole
ideas,
we're
not
saying
anything
about
what
that's
being
used
for
is
I'm,
just
cuz.
F
You
won't
use,
do
suggest
that
you
could
summarize
everything
up
with
a
slash
47.
But
the
question
is:
what
about
this
whole?
That's
sort
of
sitting
there
and
I
can't
remember
if
there
was
something
about
that
way
back
when
the
well-known
prefix
thought
was
there,
as
I
said,
my
memory
of
that
is
faded
now
over
the
years.
N
F
N
Or
I
can
just
not
suggest
that
people
used
/
47
to
refer
to
the
space,
because
these
this
prefix
on
the
RFC
6052
prefix,
are
sorry,
screensaver
see
there
you
go,
they
are
distinct.
They
are
not
overlapping,
not
really
related
to
each
other,
even
though
they
might
be
used
for
very
similar
purposes
or
even
the
same
exact
purpose.
They
are
not
related
to
each
other
really.
J
N
J
N
B
Well,
thank
you
now.
I
feel
better
that
more
people
were
involved
and
showing
interest
and
have
at
least
read
the
document
and
understand
what's
going
on,
so
I
think
it
is
time
to
respond
and
say
and
ask
whether
this
is
something
we're
going
to
do
so
we're
going
to
take
a
hum,
I'm
going
to
ask
if
you
think
we
should
adopt
this
document,
I'm
going
to
ask
if
you
think
we
should
not
adopt
this
document
and
if
I
hear
very
little
humming
in
both
directions.
B
B
B
B
L
One
slide,
so
this
was
related
to
comments
we
got
on
the
design
draft.
There
was
a
point
that
I
thought
was
important.
I
thought
it
was
important
to
bring
out
which
was
there
was
suggestions
about
you
know
v6,
you
know
we
were
talking
about
v4,
vs,
v6,
design
and
v6
is
great.
We
can
do
a
lot
of
really
cool
things,
v6.
It
can
make
operations
better,
etc.
L
What
I
thought
you
know,
I
thought
it
wasn't
appropriate
instead,
try
to
in
line
at
a
bunch
other
documents
that
might
have
other
intended
purposes
to
try
to
fit
in
all
the
greatness
of
v6
versus
what?
If
we
then
had
a
series
of
documents
if
people
are
willing
to
write
them,
that
went
and
talked
about
the
specific
use
case
and
extrapolated
a
bunch
of
information
that
was
relevant
to
how
things
are
different
with
v6
how
it's
used
there
and
you
kind
of
take
it
top
to
bottom,
showing
the
operational
components
of
it.
L
It
is
it
savings.
Is
it
beneficial
there?
Is
there
more
things
you
can
do
with
it
that
you
know
we
should
try
to
capture
these
in
separate
documents,
as
opposed
to
hiding
things
in
line
in
other
documents
like
I
mentioned
earlier,
they
had
intended
purposes
that
may
not
have
been
specific,
or
you
know
specifically
for
that
name.
That's
the
point.
I
just
want
to
kind
of
highlight
them
bring
out.
You
know
what
does
a
working
group
feel
about
this?
L
Does
that
make
more
sense,
or
do
we
continue
to
try
to
stuff
information
into
a
whole
bunch
of
the
documents?
No
one's
interested
in
this
apparently
understood
so
I
mean
that
was
the
that
was
intended
purpose
and
that's
what
I
thought
I'd
just
bring
up
and
figure
out
what
how
people
feel
about
that?
The.
E
Opinion
train
is
coming
Michael,
Abramson,
so
I
think
that
would
be
very
useful.
I
run
into
this
all
the
time
with
them.
People
are
used
to
ipv4
and
they're
trying
to
do
the
same
thing
in
ipv6
because
they
don't
really
know
what
that
you
can't
do
things
differently
in
ipv6.
That
might
actually
be
easier
and
help
them
so
I
think
that
would
be
extremely
useful.
J
Eric
line
I
frequently
find
myself
having
to
explain
to
people
that
ipv6
is
not
128
bit
ipv4
and
describe
some
of
the
ways
in
which
it's
not
a
lot
of
that
involves
pointing
at
79
34
and
a
list
of
other
documents.
The
you
know
like
the
envio
3
/
64th,
hosted
digit
center
stuff,
ila
cetera
et
cetera,
I,
don't
know
that
it
could
be
captured
in
a
single
document
without
looking
super
religious
or
you
know,
extra,
fervent
or
or
whatever,
but
trying
might
be
fun.
I
will.
K
Jana
cova
I
love
this
idea
and
it's
actually
I
like
the
timing,
because
we
just
had
was
doing
discussion
on
Eastern
European,
a
curator
circle
group.
My
link
list
about.
Yes,
we
probably
to
help
promote
enemy,
six
and
explain
to
people
how
to
deploy
it.
We
probably
need
to
document
our
sinks,
which
you
can
do
better
or
differently
and
v6
compare
them
to
a
four
year.
So
great
idea
and.
L
So,
as
you
guys,
walk
up
in
the
thought,
I
was
I'm.
Not
sure
one
document
is
the
way
to
go.
Maybe
it's
per
use
case
or
you
break
down
again.
I
have
no
intended
thought
as
to
how
we
captured,
but
I
thought
it
was
important
that
we
do
and
as
opposed
to
sticking
it
in
line
is
make
it
specific.
You
know
here's
how
top
to
bottom,
why
it's
better
and
how
we
do
it,
operationalize
it
etc.
Sir,.
S
Absolutely
I
mean
this:
you
know
that
I've
been
involved
in
ipv6
advocacy,
kind
of
work,
and-
and
this
is
the
kind
of
thing
that
is
needed
and
the
more
specific
you
can
get
and
the
more
you
can
define
what
you
found
in
this
case
or
why
you
know
anything
you
can
do
in
that
regard
is
good.
So,
yes,
I
would
say
any
of
these
docs
good.
J
Learn
security,
yeah,
I
think
that's
what
you'd
about
you!
What
you
said
jen
is
right.
It's
time
the
reason
so
when
I
saw
this
I
said
well,
wait!
That's
stupid!
Why
didn't
we
have
this
already
and
then
and
then
I
said?
Oh
that's
why
so
we
we
couldn't
have
this
because
it
would
risk
because
it
would,
it
would
have
fallen
on
deaf
ears
before
right,
if
we'd
written
as
5
years
ago,
it
would
have
been
just
more
fan.
J
S
Was
just
going
to
second
at
Dan
Yuriko
second,
go
Lorenzo's
point2
about
the
timing
wise.
The
other
advantage
is
that
we
now
have
very
solid
measurements,
etc.
You
know
that
show
when
you
start
looking
at
the
measurements
out
of
the
world,
ipv6
launch
stuff.
That
shows
that
you
know
verizon's
network
at
the
high
percentage.
It
is
the
other
networks
are
there.
You
know
it's
very
clear
that
you
know
that
ipv6
is
being
deployed
so
we're
starting
to
see
that
that
happening.
I
Jordi
palette
I
submitted
the
document
in
2006
to
this
working
group,
trying
to
explain
how
to
deploy
how
to
how
to
do
the
point-to-point
links
I
think
at
that
time
the
working
group
basically
said
you
should
not
tell
so
much
indeed
to
the
ISPs.
How
to
do
this.
Actually
I
didn't
reach
the
deadline
for
submitting
a
new
person,
but
I
think
that's
somehow
related
to
this
and
I
I
probably
also
meet
a
new
person
today
or
tomorrow.
I
think
it's
related
to
tal
this.
O
Tom
Herbert,
so
it
sound
like
a
great
idea.
One
question
I
would
have,
though,
is
is
the
intent
of
this
to
kind
of
document
experience
with
ipv6
and
say
thinking
about
some,
like
extension
header,
so
we
know
extension
headers
have
a
problem
than
the
Internet.
How
would
we
phrase
that,
in
terms
of
utilizing
ipv6
capabilities,
would
we
advocate
that
or
kind
of
say?
Well,
you
can,
but
you
my
life
may
vary.
How
would
you
phrase
that
you.
B
Might
well
say
your
luck
may
vary,
you
can
use
it
in
the
following
circumstances.
You
know
if
you
can
describe
this,
is
you
know
I'm,
just
sort
of
sorry
responding
for
you
that's
a
great
option,
although
I
also
have
a
further
question
that
I
was
about
to
ask
the
working
group,
which
is:
are
we
talking
about
writing
documents
that
describe
clever
things
that
people
have
done
with
ipv6
because
it's
ipv6
and
they
couldn't
do
it
before
or
are
we
talking
about
clever
things
that
people
could
do
with
ipv6.
L
So,
just
before
you
come
up
with
what
else,
what
again
I
was
still
thinking
through
this
I
think
baby
both
might
be
relevant
in
like
if
you
go
back
5
10
years.
It
was
a
lot
of
theory
that
we
would
have
put
towards
this
right.
We
mean
we
thought
we
knew
over
we're
going
to
get
into,
but
we've
experienced
a
lot
of
v6
over
the
last
number
year,
so
I
think
what's
going
to
happen
now
is
we
can
talk
about
practical
things
that
we've
actually
done?
You
know
case
in
point
with
Gunther.
L
In
the
you
know,
Brazil's
we
talked
about
in
Comcast's,
etc.
But
now,
if
we
extrapolate,
we
have
more
experience
by
which
to
then
base.
Maybe
some
additional
theory
on
right.
Like
I
mean
we
have
more
behind
us
to
then
figure
out
what
could
also
be
the
art
of
the
possible,
so
I
think
thick
times
have
changed
my
opinion.
You.
S
Dean
York
I
would
not
I
would
focus
on
what
have
we
learned?
What
are
the
real
things
that
are
out
there?
We
have
endless
documents
to
talk
about
all
the
things
that
could
happen
and
would
happen
if
Lee
everybody
did
ipv6
Yahoo.
Let's
talk
about
what
people
have
actually
seen
whether
they
learned
you
know
to
Eric's
point
about
the
abundance
issue
around
that
you
know.
Do
we
have
any
instances
that
people
can
show
where
they
went
ipv6
only
on
the
inside
and
got,
and
you
know
we're
able
to
take
the
people
who
are.
S
You
know
previously
spent
doing
all
the
sudden
that
allocation
stuff
that
they
had
to
go
and
figure
out
to
go
and
make
it
all
work
across
an
enterprise
when
that
were
they
able
to
retask
those
people
on
other
things,
because
they
were
able
to
make
their
internal
networks
more
efficient.
Let's
look
at
how
we
can
document
the
things
that
are
that
we
can,
you
know
are
observed
and
we've
seen
that,
because
now
we
have
real
deployments,
because
that's
what
we
need
is
real
facts,
real
things,
real
stuff
that
people
can
talk
about.
K
Angeline,
colossal
and
what
Dan
said
we
need
to
probably
recommend
what
have
been
done
to
prove
that
it's
possible
it's
beneficial,
because
there
are
countries
out
there
when
the
adoption
rate
is
like
below
one
percent
and
when
you
go
there
and
talk
to
those
people
and
ask
them
why
you
get
two
answers:
I
can't
I,
don't
know
how
and
I
don't
know
why
and
we
can
help
awesome
give
exams.
At
answer.
J
J
Can
you
know,
or
whatever
this
there's
some
stuff
that
I
can
do,
and
we
won
think
one
idea
that
I'd
have
and
which,
which
may
be
a
dumb
idea
and
I,
don't
know
until
somebody
works
out
the
math
but
like
right
now
we
have
us
and
I
right
and
and
SN
eyes
in
the
clear
and
everyone
can
see
it.
But
if
you,
if
you,
if
we
went
back,
then
it's
like,
why
do
we
do
s
and
I?
Well,
cuz?
We
don't
have
an
off
IP
addresses
right,
but
but
but
we
do
now
right.
J
So
so
you
could
say
well,
you
know
that's
one
thing
that
you
could
do
and
I
could
say:
well,
here's
how
you
use
one
ipv6
address
/
host,
and
so
you
don't
have
to
leak
anything
inside
DNS.
It's
sorry!
Instead,
the
S&I
handshake.
So
I
don't
know
that
that
seems
useful
to
document,
even
if
no
one's
actually
been
doing
it.
L
So
put
myself
back
in
line,
I
mean
I'm,
not
personal
thing.
One
excludes
the
other,
so
I
think
documenting.
What
we've
done
is
important.
I
also
think
document
we
can
do
personally
think
is
important,
because
there's
a
lot
of
as
I've
heard
is
no
list
right.
There.
People
say
all
you're
thinking
the
old
way,
you're
thinking
you're
thinking
in
a
constrained
environment.
The
answer
is
we'll
know:
let's
open,
let's
open
up
people's
minus
what
you
could
potentially
view,
although
we
may
not
have
done
it
or
not
done
at
scale.
L
I
remember
having
conversations
with
won't
name
where,
but
you
know
folks
in
the
past
and
we're
in,
we
suggested
models
that
I
gots
crazy
talk.
Who
would
do
this
but
I
think
now
we
have
enough
the
points
behind
us
where
we
can
actually
have
open
conversations
about
the
art
of
the
possible
make
based
on
experience.
So
that's
it.
Okay,.
B
So,
as
working
group
chair
knowing
this
was
coming,
it
did
reread
the
Charter
to
make
sure
that
I
knew
what
it
said,
and
it
says
that
we're
here
to
da
/
82
document,
operational
experiences
and
issues
with
ipv6
and
I.
Don't
think
we're
necessarily
describing
ipv
describing
issues
here
so
I
may
have
to
go
back
to
my
co-chairs,
an
area
director
and
say
that
I
think
there's
interest
in
discussing
this
I
think
it
made
its
require.
A
recharter
is
a
fairly
minor
E
charter.
Yeah
I
think
this
is
totally
doable
yeah.
B
So
obviously
we'll
come
back
and
ask
you
will
try
and
draft
a
charter
and
ask
if
you
like
it
but
I'm
hearing
pretty
strong
support
as
a
chair,
my
inclination
is
to
push
back
a
little
bit
harder
on
things
that
haven't
actually
been
done
if
you've
got
code,
even
if
it's
working
in
a
lab.
Yes,
that's
that's
that's
more
interesting
than
a
clever
idea.
You
had
once
in
the
shower
if
you've
actually
deployed
something
network,
that's
even
more
interesting
and
I
would
like
to
hear
that.
B
A
I'm
so
I'm
a
little
bit
mused
by
the
cases
where
we
don't
seem
to
have
experience
with
it,
because,
for
example,
like
the
prefix
edition
thing,
I've
been
binding,
prefixes
to
loop
backs
on
host
for
like
like
Eric
for
about
a
decade,
and
we
definitely
have
a
lot
of
experience
with
that
sort
of
thing.
So
I
think
we
should
be
able
to
tease
out
the
ones
that
we're
we're
quite
comfortable
with
I
think
pretty
easily
yeah.
If
no
one
does
it
then
well,
I,
guess
we're
sort
of
speculating
about
thing
and
I.
B
A
J
K
Jana
cova
1
colon
I
just
realized
that
probably
we
do
not
have
the
right
people
in
the
room,
because
there
is
a
community
out
there,
mostly
bc,
o
P
community
and
a
natural
population
group
like
one
a
tripe
and
another
region,
and
it's
probably
right
people
too.
We
should
reach
to
hear
what
they're
doing
and
do
it
the
comment
about
if
people
has
not
done
it
yet
probably
smoke
needed.
Sometimes
people
do
not
do
it
because
they
don't
know
about
that.
All
they
do
not
have
required
functionality
yet
so.
B
I
am
very
friendly
to
your
suggestion
that
operators
should
give
input
to
the
v6
operations
working
group
very,
very
friendly
to
that
one,
and
so,
and
I
agree
that
there's
definitely
room
within
the
IETF
to
discuss
things
that
haven't
been
done
before.
That's
a
great
place.
I'm,
not
sure
v6.
Ops
is
the
place
to
publish
documents
for
fresh
brand
new
ideas,
but
willing
to
discuss
that.
As
we
talk
about
our
charter.
T
Mike
Ackerman
I
was
going
to
ask
who's
the
intended
recipient
of
this
document
and
I
hope.
It's
me,
the
enterprise
that
seems
incapable,
Mike
Ackerman
of
deploying
ipv6
and
we're
not
alone
is
we
do
need
all
the
help
we
can
get
so
and
I
was
just
going
to
add
one
bit
of
advice
to
try
to
keep
it
somewhat.
Business
oriented
I
like
all
the
technical
stuff
but
you're
going
to
blow
us
away
and
it
won't
achieve
the
desired
results.
I
don't
think
so.
I.
B
Don't
know,
I
think
the
who
we,
after
here
there
may
there
may
be
multiple
things.
I
think
that
what
I
thought,
what
I
heard
from
victor
is
that
there's
interest
in
saying
here
are
some
cool
new
things
that
you
can
do
with
ipv6,
that
you
couldn't
do
in
ipv4,
which
probably
would
be
targeted
at
people
who
are
thinking
about
deploying
ipv6
and
trying
to
develop
more
reasons
to
support
that.
But
I
don't
speak
for
Victor
and.
T
L
I
mean
there's
more
than
one
way
to
look
at
this.
However,
one
of
the
things
I
was
thinking
about
is
probably
I
mean
we
are
technology
organization,
so
I
think
the
technology
has
to
show
up
somehow
in
the
writing.
Probably
a
rollup
of
that,
whether
that's
done
here
or
elsewhere,
I
mean
I,
didn't
mean
leave.
L
Agree:
I
love
it.
My
boss
won't
understand
it,
so
we
won't
do
it.
Yeah
I
mean
I,
think,
expand
and
simplify.
So
we
have
the
details.
We
have
the
information
and
we
simplified
and
it
gets
simplified.
I'm
not
don't
know
who
would
do
this
and
how
we
do
this,
but
I
agree
because
you
want
to
take
it
up
to
business.
Speak
at
some
point
where.