►
From YouTube: IETF101-V6OPS-20180319-0930
Description
V6OPS meeting session at IETF101
2018/03/19 0930
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
A
So
now
agenda
bashing:
this
is
our
agenda
this
morning,
we've
got
to
well.
Well,
we
have
an
invited
talk.
We
have
two
working
group
drafts
and
then,
frankly,
we
had
some
open
space
in
the
agenda
and
we
had
a
bunch
of
drafts
that
got
very
little
discussion
really
on
blessed
and
so
I
went
ahead
and
put
them
in
there
and
if
you
don't
like
that,
throw
the
exit
thing.
I
do
have
one
question:
Fred
Templin:
are
you
online.
C
A
Have
one
kind
of
opening
chair
comment
before
we
get
started,
and
that
is
that
we're
reducing
the
number
of
chairs,
literally
literally
so
Lee
and
Ron
and
I,
had
been
co-chairing
this
just
working
group
Lee
has
become
a
busy
boy.
He's
got
to
start
up,
so
he's
going
to
no
longer
be
a
chair
here
and
I
want
to.
Thank
you
for
your
efforts.
Thank
you.
A
D
A
C
C
So
the
history
of
the
draft,
this
document
has
been
around
for
some
time
now.
The
zero-zero
was
posted
in
November
of
2015
and
announced
to
be
six
ops.
We
had
a
couple
of
draft
revisions
based
on
list
comments,
then
in
July,
in
August
of
2016,
the
internet
draft
review
team,
which
was
part
of
the
ipv6
administrative
team
at
that
time
reviewed
the
draft
and
that
resulted
in
the
publication
of
the
0-3.
C
C
Think
we're
in
sync
Fred
if
I
get
out
of
sync,
though
just
let
me
know:
okay
cool
so
case,
one,
the
classic
riding
model
here.
In
this
case,
the
network
n
delegates
prefix
P
to
rest
requesting
router
are
are,
can
sub
delegate
the
prefixes
from
P
the
downstream
networks
or
assign
addresses
from
ASA
by
taken
from
prefix
P
to
a
downstream
interface
and
hosts
H
sub
I
assign
addresses
a
sub
I've
taken
from
P
and
may
also
further
sub
delegate
exists
from
P
on
their
downstream
interfaces.
C
F
C
C
C
C
Next
chart
case
three
is
known
as
the
straw
den
system
model.
In
this
model,
our
can
assign
addresses
a
sub
I
to
an
upstream
interface
without
invoking
ability
or
bad
and
example,
is
any
host
that
cannot
assign
addresses
to
any
other
interfaces
beside
the
upstream
interface,
and
this
is
exactly
the
case
that
we
found
when
we
ran
openvpn
on
the
androids.
C
We
found
that
if
we
got
a
prefix
delegation
from
the
Open
VPN
server,
the
client
could
not
assign
addresses,
take
them
from
that
prefix
to
a
virtual
interface
or
a
physical
interface,
and
so
it
had
no
other
interface
to
assign
them
to
except
the
upstream
interface.
But
once
we
assign
the
addresses
to
the
upstream
interface,
then
ipv6
applications
work
on
the
Android,
but
device
is
just
fine
on
next
traffic.
C
Changes
since
I,
we
changed
the
title
from
prefix
delegation
for
hosts
to
ipv6
prefix
delegation
models,
and
that
was
based
on
this
comments.
We
have
a
new
section
on
address,
auto-configuration
considerations.
It
cites
RFC
6430
for
this
section
6.
As
the
reference
for
auto
configuration
requirements
for
nodes.
It
acknowledges
that
subnet
router
anycast
address
must
be
honored.
C
Next
chart
now
here
is
where
we
might
be
getting
a
little
bit
of
a
controversial
section
is
that
we
have
a
new
section
on
prefix
delegation
services.
This
is
based
on
this
comments.
This
new
section
says
selection
of
prefix
delegation
services
must
be
considered
according
to
specific
use
cases.
An
example
services
that
offered
by
dhcpv6
an
alternative
service
based
on
ipv6
neighbor
discovery
messaging
has
also
been
proposed,
and
you
see
it
pointed
to
a
document
called
the
PIO
x
document.
C
As
a
new
example
that's
being
considered,
then
it
says
that
other
non
router
mechanisms
may
exist,
such
as
proprietary
IP
MS.
I
deanna
my
perfect
print
management
and
ID
son
CA
sm
address
pool
management
yang.
So
what
this
session
is
essentially
saying
is
that
we're
not
only
considering
just
one
piece
if
Excel
gave
in
service
but
we're
leaving
open
alternatives
for
four
possible
futures
prefix
delegation
services
that
might
might
be
published
next
chart,
so
the
questions
I
have
for
the
working
group.
C
Do
we
want
to
remain
prefix
delegation,
service,
agnostic
or
focus
on
one
specific
service
like
yet
DHCP
prefix
prefix
delegation?
Then
what
do
we
want
to
call
the
end
systems
that
receive
a
prefix
delegation
host
router
node,
something
else
and
then
the
the
third
point
is.
Does
the
answer
to
Question
2
depend
on
the
weak
host
strong
host,
the
distinction
as
to
whether
we
call
it
a
host
or
a
router
or
a
node
and
I?
Think
I'm
out
of
charts?
Now.
A
Ok,
so
yeah
I
asked
you
for
a
10-minute
talk.
It's
actually
been
about
10
minutes
now,
so
I'm
not
sure
we
have
time
at
this
point
to
go
to
the
mic
and
discuss
these.
What
I'm
going
to
suggest
is
that
people
please
comment
on
these
questions
on
the
list
so
that
we
have
AB
that
discussion
and
Fred
can
respond
to
it
was
that
fair
friend,
all
right
sure,
Fred,
that's
fine,
yeah,
okay,
so
I'm
gonna
move
move
ahead.
G
That
makes
a
big
difference:
hi,
okay,
I'm
Pete,
Stevens
I'm,
the
director
of
mythic
base,
limited
and
I'm
terrible
of
working
microphones
and
we've
done
a
decent
amount
of
ipv6-only
hosting,
which
is
why
I'm
here
we're
a
small
hosting
company.
So
most
of
the
people
who
talk
about
v6
are
kind
of
hyper
scale,
Facebook
Google,
sighs.
We
don't
have
as
many
servers
as
Google
or
Facebook,
probably
not
even
1%,
of
the
number
of
servers
they
have
so
we're
a
bit
of
a
different
use
case,
and
so.
G
G
Our
most
exciting
container
rollout
is
now
pushing
400
containers
on
a
single
machine
and
therefore
needs
400
Network
addresses
and
we're
looking
pretty
good
at
eating.
A
thousand
Network
addresses
per
machine
fairly
soon,
which
is
great
because
a
thousand
IP
is
on
the
open
market,
cost
considerably
more
than
the
server.
So
we
have
a
problem
which
is
we
can't
afford
to
use
an
IP
for
every
container,
so
hello,
NAT?
G
So
you
may
notice
the
seven
layer
OSI
model
these
days
where
you
have
a
physical
layer
and
then
we
have
Ethernet,
and
then
you
have
a
UDP
layer
that
implements
an
overlay
network
that
implements
UDP
that
implements
another
overlay,
Network
your
container
infrastructure
that
might
implement
TCP
if
you're,
lucky
and
then
you've
got
HTTP
on
the
top
and
that's
what
the
docker
kids
call
rita
and
they
start
implementing
other
protocols.
G
On
top
of
that-
and
this
is
no
fun
and
so
and
the
brief
economics
argument
I'm
sure
you're
well
familiar
with,
which
is
I,
can
turn
up,
go
to
write
and
get
a
slash,
22
but
dress.
Space
I
can
sell
my
VMs
at
10
pound
a
month,
and
that
means
I
can
build
a
hosting
company
that
generates
a
hundred
thousand
pounds
a
year
and
then
it
runs
out
of
ipv4
addresses
and
that's
it
for
company
expansion.
Thank
you
for
becoming
a
new
player
in
the
hosting
market.
G
Your
game
is
over
already
because
you
can't
afford
the
24/7
ops
team,
and
so
if
ipv4
addresses
were
free,
our
life
would
be
much
better.
Iq.
V6
addresses
effectively
are
free,
so
this
leads
to
the
obvious
question:
can
I
do
stuff
with
ipv6
addresses,
but
more
importantly
and
I'm,
good
friends
with
the
people
at
Raspberry
Pi,
and
they
like
to
remind
me
that
an
ipv4
address
is
now
$24?
G
According
to
ipv4
market
group
and
they'll
sell
you
a
computer
for
five,
you
can
have
five
computers
cheaper
than
the
octet
so
and
yeah,
and
we
have
a
problem
that
the
address
space
is
too
expensive
and
it's
just
an
economics
problem.
It's
not
a
technical
problem.
We
can't
afford
the
addresses.
What
are
we
going
to
be
so
we
implemented
v6
a
while
ago,
any
of
our
VMs
can
talk
v6
or
before
we
give
you
a
v4
address
from
the
DHCP
server.
G
We
give
you
a
block
of
v6
addresses
and
we
have
this
magical
thing
called
slack.
That
gives
our
servers
completely
random
addresses,
which
means
we
don't
know
s
and
inbound
services
which
is
really
annoying
and
and
also,
if
you
enable
slack
on
hosting
network.
All
of
your
customer
machines
enable
a
v6
address,
use
it
for
outbound
traffic
all
appear
in
the
same
64
and
then
immediately
get
blocked
by
everyone
else's
mail
server.
So
you
can't
do
that.
G
So
that's
not
very
helpful,
and
so
you
can
use
DHCP
six,
but
that's
a
world
of
pain
in
its
own
way,
because
the
installers
tend
not
to
like
it.
If
your
gateway
address
is
not
in
the
same
64
that
you're
trying
to
give
to
the
customer.
If
you're
giving
every
customer
the
round
64
you
need
an
address
on
the
router
for
every
single
custome
you
need
and
it
all
gets
really
horrid.
So
the
easy
trick
is
just
static,
address
everything.
G
So
the
next
problem
is
your
v6.
Only
machine
means
to
have
a
v6
resolver
in
order
to
work
out
how
to
go
and
download
an
update.
So
we
start
at
the
address
we
use
routes
or
advertisements
to
advertise
our
gateways.
So
that
way,
if
I
Rita
disappears,
the
advertisement
goes
away
and
it
falls
back
to
the
other
one.
G
This
is
a
really
nice
way
of
doing
a
decent
level
of
redundancy
for
virtually
no
effort,
and
the
problem
you
get
is
most
operating
systems
use
a
mirror
service
and,
whilst
the
mirror
director
speaks
Jill
stack,
it
doesn't
know
which
of
its
mirrors,
our
dual
stack
or
v6.
Only
so
it
will
hand
you
a
URL
for
a
v4
only
mirror
that
you
can't
get
to
because
you're
on
a
v6
heading
machine
and
on
top
of
that,
an
awful
lot
of
services
on
the
internet
don't
have
v6
either
so
as
a
product.
G
This
is
and
don't
buy
it
so
yeah.
It's
really
not
very
useful,
so
part
of
the
problem,
not
six
for
skipping
very
quickly.
We
synthesized
v6
addresses
for
everything
we
can
go
to
as
your
LAN
does
here.
It
works
very
nicely
and
solves
a
big
chunk
of
your
problems,
so
we
now
have
outbound
traffic.
We
can
get
updates.
Our
server
works.
G
So
inbound
inbound
traffic,
we
need
other
people
who
don't
have
v6
to
be
able
to
see
the
stuff
on
your
machine.
So
we
have
a
central
proxy
service
called
proxy
method,
be
so
calm,
it's
implemented
with
hecho
proxy.
If
you
go
to
our
control
panel,
you
can
just
go
and
type
in
this
is
my
URL.
This
is
my
back-end
server.
It
also
configures
itself
and
magically
all
of
your
stuff
gets
tunneled
through.
G
It
accepts
v4
and
v6
and
then
forwards
it
onto
the
backend
and
it
does
HTTP
and
any
service
that
supports
SSL
but
use
it
SNI
Windows
XP
has
died.
We
don't
have
to
worry
about
things
that
don't
do
a
sanai
anymore
and
it
doesn't
forward
SSH,
which
is
the
really
annoying
thing.
So
you
can't
SSH
into
your
v6
only
server
if
you've
got
a
v4
only
on
your
client,
but
from
the
point
of
view
of
giving
services
out
to
users.
G
Try
that
again,
so
this
gives
us
an
actually
useful
product.
We've
got
a
VM,
it
consumes.
One
v6
stress
only
has
outbound
traffic,
it
has
inbound
for
SSL
and
HTTP,
and,
and
you
can
host
websites
on
it
like
Raspberry
Pi
dorg,
which
is
done
exactly
that
way
and
is
one
of
the
busiest
sites
in
the
UK
and
so
for
us.
G
We
poly
we've
now
got
40
odd
VMs,
saying
at
the
backend
that
actually
put
everything
together
that
do
HTTP
and
databases
and
memcache
and
all
the
different
bits
of
their
site
and
the
whole
thing
gets
stuck
together
by
the
front
and
proxy
and
there's
no
v4
at
all
on
any
of
the
atoms,
because,
as
long
as
everything
uses
SSL,
it
all
works.
Fine.
G
Thank
you
so,
and
most
of
what
we
do
actually
is
manage
your
VMs
for
you,
and
so
we
realized
that
as
soon
as
we
deployed
a
server
that
didn't
have
a
v4
address.
All
of
our
management
services
hat
support
v6,
and
this
was
the
kind
of
biggest
bit
of
effort
in
making
this
go
so
backup
server.
We
just
had
to
add
a
cord
a
record,
and
then
we
could
back
out
so
our
backup
server.
Prior
to
that
it
turns
out
what
happens.
G
Is
everything
backs
up
three
on
that
six
for
proxies,
which
gives
you
a
really
nice
bandwidth
graph
on
your
assets
for
proxies
so
yeah?
You
learn
that
one
very
quickly
and
monitoring
customer
machines.
We
have
to
monitor
the
v6
addresses
at
the
back,
and
we
had
to
explain
to
our
control
panel
that
it
was
allowed
to
talk
to
v6
addresses
because
a
bunch
of
it's
written
in
Perl
and
until
you
have
a
version
of
WWI
cognized
that
support
v6.
That
didn't
work
very
well
at
all.
G
Thank
you,
and
so,
where
it
got
more
fun,
is
we
use
meaning
to
graph
everything
up
great
meaning
to
the
later
server?
Let's
get
these
export
at
v6,
the
Munich,
so
you
mean
in
server
all
of
your
graphs
break
and
that's
partly
because
you've
got
a
lot
date.
The
beam
in
config
file
on
every
single
clients
to
know
that
it
can
now
talk
to
your
v6
dress
and
also
it
has
that
entertaining
syntax
for
a
v4
address
if
you're
also
v6
capable.
G
Turn
it
off
because
it's
flaky
right
I'll,
look
this
way
then
yes,
and
that
apparently,
is
a
v4
address,
embedded
in
v6
embedded
in
some
escaping
rubbish,
because
meaning
isn't
very
clever
yeah
that
was
fun
but
yeah.
That
was
an
extremely
boring
few
days,
but
all
in
all,
eventually
it
works
next
one.
G
So
we
then
had
to
go
and
update
all
of
our
code.
The
auto
magic
dually
generates
all
of
our
management
services
so
that
it
could
correctly
escape
out
v6
addresses
because
they
need
square
brackets
around
them
when
V
Falls,
don't
that's
really
annoying
and
and
yeah.
There
are
lots
and
lots
of
bits
of
our
control
panel,
where
we'd
asserted
that
a
server
had
a
v4
address.
That
is
an
assumption
that
gets
broken
as
soon
as
you
deploy
a
verse.
G
First
v6
only
machine
once
you've
done
that
you
then
start
turning
v6
on
by
default
for
every
single
customer
installed.
You
ever
do
next
one
please
so
another
bit
is
every
day
our
machines
login
a
whole
bunch
of
data
about,
what's
going
on
so
and
if
you've
ever
been
handed
a
machine
completely
cold.
Where
someone
has
said,
I've
got
the
server
on
the
internet,
but
don't
think
it's
working
properly.
You
know
about
servers.
G
Unfortunately,
because
this
is
also
deployed,
it
uses
the
IP
address
as
a
key
to
work
out
which
machine
it's
come
from
on
a
dual
stamp
machine.
That
makes
everything
much
more
exciting,
because
you've
got
a
bigger
variety
of
IPS
that
stuff
may
come
from,
so
he
had
some
implements
a
load
of
stuff
that
would
go
and
read
the
reports
we
got
from
them
and
start
matching
up
the
MAC
addresses
in
the
report.
We
got
to
work
out
which
actual
server
this
came
from,
because
IP
address
is
no
longer
good
enough.
G
It
telling
you
we
also
have
jump
box,
which
is
how
we
log
into
things,
so
it
automatically
works
out
which
customer
key
you
should
be
using
when
you
go
and
log
into
a
customer
machine,
because
each
customer
has
a
different
key
now.
We've
got
multiple
addresses
every
target
machine,
so
yeah
more
intelligence
required
to
deal
with
that.
A
good
chunk
of
this
is
actually
just
that
our
code
wasn't
multi
address
away
rather
than
v6
specific,
it's
just
that
envy
fall
and
no
one
can
afford
to
address
this
per
machine.
G
So
we
haven't
really
had
to
deal
with
the
problems,
but
the
really
nice
thing,
of
course,
is
because
our
jump
box
is
dual
stack
and
everything
we
do
on
a
customer
survey
has
to
go
through
our
job
box.
It
doesn't
matter
if
I
don't
have
v6
on
my
desktop
at
any
given
time,
because
in
order
to
log
into
a
machine,
I
have
to
go
over
our
jump
box,
and
that
means
I've
got
v6
into
the
customer
server.
G
So
one
of
the
things
we're
continually
doing
is
improving
our
customer
deployment
for
particularly
managed
customers.
So,
ideally,
we
want
to
get
to
the
point
of
you
press
a
single
button
and
up
pops
an
entire
automatically
manage
customer
installation
that
does
whatever
they
want
and
we
got
to
attempting
to
do
your
next
set
of
automation
and
Jill
stacks
really
horrid.
G
Having
to
do
everything
twice
set
all
of
your
firewalls
up
twice:
don't
hide
your
stock,
jewel,
snacks,
really
painful,
and
so
we
concluded
it'd
be
much
easier
to
just
ev4
or
just
ev6,
but
obviously
anyone
who
starts
off
v4
only
is
going
to
become
jewel
snack.
So
we've
got
to
take
that
pain
anyway,
and
then
we
concluded
that
the
easy
solution
to
this
was
we
just
ev6.
G
Previously
mentioned
slack
is
not
very
nice
from
our
point
of
view.
The
HP
six
is
not
that
nice
either.
Link-Local,
however,
is
great.
Every
machine
starts
up
and
it
has
a
link-local
address.
So
what
you
can
do
when
you
first
start
a
machine
from
image?
Is
you
can
nip
to
a
known
link?
Local
address
that
you
know
will
be
present
on
the
LAN
pull
up
a
file
that
contains
the
entire
conflict
of
how
you're
going
to
set
yourself
up
and
then
write
all
of
your
static
configuration
there
I'm
so
yeah,
it's
a
single
HTTP
call.
G
You
can
don't
beat
up
that
writes
all
of
your
confident
and
the
automatic
missive
link-local
is
brilliant
for
us
and
it
means
we
don't
have
to
deal
with
the
OSHA
p6
or
slack,
both
of
which
are
horrid
and
I,
don't
like
either
of
them.
So
that's
definitely
an
improvement
from
our
point
of
view.
I'm,
sorry,
if
I'd
review,
anyone
here
works
on
the
HTTP,
6
or
slack
next,
please.
G
So.
The
next
question
is:
how
do
you
persuade
the
customers
to
buy
this?
Because,
from
our
point
of
view,
this
is
the
whole
purpose
of
this.
Is
to
be
able
to
sell
services
to
customers
that
don't
consume
v4
addresses
until
we
sold
a
service
that
doesn't
use
a
v4
address.
We
haven't
achieved
anything
at
all,
because
we
still
have
a
hardly
my
own
company
expansion,
which
is
running
out,
v4,
addresses
or
slides
for
that
matter.
So
and
the
first
thing
we
concluded
we
do,
is
we
itemize
v4
addresses?
G
If
you
have
a
v4
address
on
a
service
from
us,
it
is
itemized
on
your
bill.
There
is
a
thing
that
says
you
are
paying
20
pounds
a
month
for
the
v4
address,
and
this
is
brilliant.
Accountants
do
not
know
what
ipv4
addresses
are
and
accountants
do
not
like
for
paying
for
things.
They
don't
understand.
G
G
I
need
them,
and
if
you
go
back
to
the
Accounts
Department
and
say
don't
think
so,
the
Accounts
Department
goes
to
the
technical
department
and
they
say
why
are
we
spending
40
pounds
a
year
when
the
company
sells
it
to
us
say
we
don't
need
it,
and
this
gives
your
technical
department
two
choices.
One
of
them
is,
they
can
explain
to
accounts
why
they
want
to
keep
their
v4
addresses
and
the
other
one
is.
They
can
migrate
to
v6
techies
hate
the
Accounts
Department.
They
really
hate
them.
G
So
that
is
an
astonishingly,
powerful
motivational
tool
and
it's
not
about
the
money
it's
about.
We
just
hate
accounts
next,
please
so
that
genuinely
does
work
so
and
similarly
and
the
bit
that
works
equally.
Well,
when
deploying
new
services,
you
turn
on
to
us.
As
a
customer,
you
know
existing
customers
sign
up.
No
I
aren't
even
new
server
and
some
v4
addresses
it's
like.
Oh
sure,
you
can
have
an
Eevee
for
address,
go
and
fill
in
this
a
purchase
order
from
accounts
to
get
every
four
address
or
have
us
laugh
64?
G
G
We've
got
a
fair
few
technical
customers
who,
like
ipv6,
want
to
learn
stuff
about
it
or
increasingly
would
be
embarrassed
that
the
fact
they
don't
have
v6
so
yeah
and
since
I
first
gave
this
talk.
That
was
now
expanded
to
include
things
like
the
v6
Council
in
the
UK
UK
network
operators
for
around
the
london
internet
exchange
and
so
on.
G
We've
had
a
few
dns
anycast
services
because
it
turns
out
to
be
relatively
useful
for
some
reason
and
the
rest
of
them
are
actually
non-technical,
managed
customers
who
don't
want
our
v4
addresses
and
are
quite
happy
that
they
haven't
bought
them
and
and
actually
that's
the
real
win,
because
if
we
can
sell
to
those
people
we're
really
getting
somewhere
because
it
means
we're
moving
towards
a
v6
only
future
and
the
end
users
don't
know,
and
the
whole
thing
is
transparent,
so
yeah.
So
the
conclusion
here
is:
dual
stack
is
rubbish.
G
My
view
is,
if
you
want
to
come
up
with
the
dumbest
migration
plan
to
v6,
you
can
imagine
it
is.
Everybody
becomes
dual
stack
when
everybody
is
dual
stack.
We
deploy
v6
only
and
start
turning
v4
off,
because
I
have
a
friend
called
James,
he's
really
bloody-minded
and
he
doesn't
want
to
deploy
v6
and
if
I
have
to
wait
for
James
boy
v6,
it's
never
going
to
happen.
So,
basically,
it's
much
easier
to
say
we
have
v4
over
there.
G
We
have
some
dual
sniper
talks
both
and
we
have
v6
only
over
here-
and
this
is
the
world
were
actually
in
because
there's
increasingly
large
piles
of
v6
only
and
we
have
some
translation
in
the
middle
and
then
it's
just
make
it
easier
to
deploy
into
v6
land
and
harder
to
deploy
in
v4
land,
and
eventually
everything
will
gradually
gradually
move
over.
So
and
what
goes
with.
This
is
the
thing
that
gives
you
persuade
you
not
to
go
and
deploy
things
into.
G
G
In
the
event,
the
datacenter
fails
is
to
automate
their
entire
config,
so
they
could
rebuild
their
entire
system
in
a
new
environment,
rather
than
have
to
deal
with
the
fact
that
you've
got
to
join
perova
network
that
doesn't
have
a
flat
lap,
because
VPNs
are
nasty
and
you
need
to
get
a
networking
engineer.
Engineering
team
talking
and
the
networking
engineering
team
don't
talk
anywhere
near
as
fast
as
your
public
code
and
so
on.
So
yeah
you're
stuck
it's
horrid.
Nat
is
horrid
and
so
ya
don't
deploy
dual
stack.
G
If
you
can,
if
you
can
avoid
doing,
Joule
stack
avoid
it
just
to
play
v6
only
and
narrow
down
all
of
your
v4
v6
things
to
the
smallest
number
of
machines
and
primarily
I'm,
really
sad
to
say
the
main
reason
I
want
to
do
v6.
Is
it
just
not
as
horrid
as
NAT
yeah?
That's
it.
It's
I
think
it's
not
somewhere.
I
want
to
be
I'd
really
like
to
just
live
in
a
land
where,
in
my
v4
addresses,
were
free
and
infinite,
and
everything
worked
first
time,
but
no
it's
basically
NAT
is
so
horrible.
G
I
have
been
prepared
to
deal
with
a
bunch
of
the
nastiness,
those
v6
and
so,
which
is
how
I
got
to
where
I
am
next.
Please
so
next
question:
does
it
actually
work?
Is
it
viable
to
try
and
deploy
things?
If
you
don't
have
v4
addresses,
so
everything
needs
to
support
single
stack
v6
and
in
our
case
we
substantially
reduce
the
scope
of
the
problem
because
we're
a
Linux
shop
we
run
Debian,
Ubuntu
and
CentOS,
and
and
that's
it
so
Windows
doesn't
support
v6.
G
Only
don't
care,
don't
know,
FreeBSD,
don't
care,
and
so
yeah
we've
substantially
cut
their
complexity
there
and
we
give
each
customer
slash
64
of
their
own,
and
this
is
a
requirement
because
everybody
else
filters
things
like
mail
on
/
64
boundaries.
So
if
you
have
1
/
64
for
your
entire
subnet
and
your
data
center,
one
of
your
customers
and
spam,
nobody
can
send
email
anymore.
That's
really
annoying.
F
G
G
G
G
Absolutely
fine
and
WordPress
has
a
million
and
one
plugins
which
are
extremely
variable
in
quality
and
may
not
work
v6
only
or
an
acceptable
speed
on
a
website
that
anybody
ever
looks
at
or
in
fact,
at
all,
so
one
of
the
biggest
problems
you
have
trying
to
work
out.
Why
your
WordPress
plug-in
doesn't
work
in
your
v6.
Only
environment
is
the
failed
assumption
that
it
works
anyway.
G
Uploaded
it
again
and
all
of
our
problems
went
away,
so
that
was
nice
next,
please
and
so
other
other
plugins
WooCommerce
for
selling
stuff.
That
works.
Fine
gravity
forms
for
having
fill
in
forms
that
one
works.
Fine
super
cache
is
the
one
that
makes
WordPress
actually
work
fast
enough
that
more
than
three
people
can
look
at
it.
On
the
same
day
that
one
works:
fine,
too
search
engine,
optimization
yep
that
works
fine
spam
filtering
as
long
as
you've
got
your
nice
Explorer
proxy.
G
In
so
it
can
call
out
to
the
spam
filtering
service
that
doesn't
support
v6
again,
fine,
basically
all
the
well.
These
plugins
they
just
work
and
you
can
reliably
bring
up
WordPress
and
tell
the
customers
to
go
and
install
any
plug-in
they
feel
like.
And
if
the
plug-in
doesn't
work
in
a
v6
and
the
environment
is
probably
because
the
plug-in
it
doesn't
work
at
all.
So
yeah,
that's
pretty
good
next,
please,
and
so
we
grew
from
that
and
we
do
WordPress
as
a
managed
service,
and
so
we
basically
apply
right.
G
Thralls
give
us
a
technical
justification
in
order
to
get
an
additional
ipv4
address,
except
that
we
count
from
zero
because
we're
computer
scientists.
So
by
default
you
get
zero
ipv4
addresses
and
you
have
to
give
us
a
justification
to
get
the
first
one
and
and
they're
extremely
rare.
Most
of
our
work
managed
repair
services,
sits
on
v6
and
VMs
and
hide
behind
our
proxy
service
and
most
of
the
customers
either
haven't
noticed
or
don't
care
or
don't
know.
So
that's
that's
going
well
and
at
that
point,
I've
successfully
achieved
something.
G
I
can
continue
to
sell,
managed
WordPress
services
in
the
event
that
no
v4
address
ever
becomes
available,
and
that
gives
us
a
path
to
grow
our
business.
Unfortunately,
it
means
all
we
have
to
do
is
manage
WordPress,
which
is
not
really
the
business
I
wanted
to
run,
but
it's
something
right.
So
yeah
we've
got
something
next,
please
so
from
that.
We
started
to
expand
out
and
start
looking
at
other
things.
So
MediaWiki
we've
done
some
managed
media
wiki
for
people
and
again
it
all
works.
G
Fine
because
it's
a
patchy
lamp
stack
and
internally,
it
uses
nodejs
and
something
called
porous
oyd
in
order
to
have
the
nice
graphical
front
and
the
mangles
all
of
your
HTML
really
badly
and
apparently
that's
important
but
yeah
internally,
it
box
talk,
support,
8000
and
you
have
to
fiddle
a
config
file
to
make
it
spot
that
you've
got
v6
and
the
UK
NOx
wiki
is
built
on
top
of
that
and
that
all
works.
Fine.
G
Next,
please
and
let's
encrypt,
let's
encrypt,
is
a
brilliant
solution,
because,
as
I
said,
you
have
to
use
SSL
in
order
to
sit
behind
a
v6
proxies.
Ssl
is
now
free
and
thanks
to
let's
encrypt,
it's
also
now
really
easy
and
you
don't
have
to
continually
renew
certificates
and
copy
files
around
the
place
and
get
people
to
reply
to
emails
because
nobody
replies
to
their
email.
So,
yes,
it's
great.
It
works
out
of
the
box
behind
our
proxy
that'll.
Just
works.
Absolutely
fine,
there's
no
difference!
It
now
also
does
pure
v6
as
well.
G
So
if
you
decide
you,
don't
even
want
it
off
of
v4
at
all,
you
can
still
use
it,
let's
encrypt
and
have
us
a
cell.
So
yes,
let's
encrypt,
is
one
of
the
things
that
makes
this
much
easier
because
it
removes
the
customer
objection
to
having
SSL.
And
so
yes,
we
like
that.
Next,
please,
london,
internet
exchange,
so
they've
just
rebuilt
their
website.
G
They
had
a
horrid
content
management
system
that
was
very
hard
to
update
and
losing
security
sport
and
they
said,
should
we
base
it
on
wordpress,
and
we
said
yes,
that's
what
all
content
driven
sites
are
basically
built
with
your
life
will
be
easier,
so
we
manage
it
for
them.
We
forgot
to
turn
the
proxy
on,
but
the
London
internet
exchange
have
v6
everywhere
and
it
was
actually
28
days
until
anybody
noticed
that
they
didn't
have
any
v4
at
all
on
their
dev
websites.
G
G
So
that's
FRP
after
I/o
it's
a
URL
shortener
which
is
used
by
raspberry
pi
and
basically
they
used
to
use
bitly,
which
is
of
course,
a
very
well
known,
but
URL
shortener
and
basically
bitly
as
a
service
that
writes
HD
map
htaccess
file
with
some
redirects
in
it,
but
has
a
slightly
nicer
user
interface.
Next,
please,
and
so
we
emailed
them
and
said:
can
we
use
our
own
domain
name
and
they
said
yeah,
it's
695
dollars
a
month
and
then
who
was
their
manager
said?
G
Did
you
miss
a
decimal
point,
even
six
dollars
95
a
month?
So
in
the
true
open-source
tradition,
we
decided
not
to
pay
$700
a
month
for
a
trivial
service
and,
of
course,
just
deployed
around
max.
Please
so
yeah
there's
a
little
PHP
application
that
does
this.
It
absolutely
works.
Well,
it's
fine,
and
if
you
don't
like
PHP
and
want
to
do
it
in
Python,
you
can
offer
it
one
as
well.
G
It
also
works
fine,
so
you
can
use
that
instead,
alternatively
yeah
you
know,
but
there's
loads
of
them
next,
one
please
and
etherpad
open-source
alternative
to
Google,
Docs
and
yeah
shared
document,
editing
written
in
no
js'
and
lessons
fine
requests
come
in.
We
forward
traffic
to
it
when
it
makes
connections
out
it's
a
bit
special
next,
please
so
you've
heard
of
happy
eyeballs,
happy
eyeballs
is
where
you
look
for
v6
and
try
to
connect
to
v6
and
if
it
doesn't
work
you
go
back
and
connect
to
v4.
G
Nodejs
is
a
bit
more
exciting
than
that,
so
it
does
the
court
I
look
up
and
on
that
sixth
floor
resolver
gives
it
a
v6
address
for
the
service.
It's
trying
to
talk
to
it
then
doesn't
a
lookup
I!
Guess
if
you
for
address,
and
then
it
tries
to
connect
to
the
v4
address,
fails
and
stops
because
it
never
tries
to
connect
to
the
v6
address
if
a
v4
us
address
is
present
at
all.
G
So
if
you
put
the
quad
a
record
in
the
etc
hosts
file,
it
turns
out
the
lookup
doesn't
succeed,
getting
an
a
record
and
then
it
connects
to
v6,
because,
obviously
you
came
from
the
v6
support
and
then
just
switch
it
off
yeah.
So
now
it
connects
outwards.
So
next,
please
so
again
conference
booking
system
in
decay,
we've
done
a
few
managed
installs
of
those
nodejs
same
set
of
problems
adds
in
Redis
and
memcache.
G
That's
exciting
I
guess
one
or
the
other,
but
there
you
go
cache
early
cache,
often
and
so
yeah
we've
got
a
few
indica
and
source
managing
conferences.
They
all
work,
fine
in
the
v6
and
the
environment.
Next
one
Sugar
CRM,
those
of
you
who
don't
like
salesforce-
and
this
is
a
gigantic
CRM
system,
and
so
it's
again
Linux
Apache
MySQL
PHP,
but
adds
in
elasticsearch,
which
is
written
in
Java.
It's
on
top
of
Tomcat
and
memcache
D
we're
running
split
site
instances,
because
sales
people
have
no
patience.
G
If
their
website
is
down
and
so
their
high
availability,
you
can
flip
over
between
them
relatively
quickly
and
because
elasticsearch
and
memcache
D
don't
support
a
multi-tenant
environment.
We
need
to
have
a
separate
copy
of
elasticsearch
and
a
separate
copy
of
memcache
D
for
every
single
customer.
That's
using
Sugar
CRM,
so
we
decided
that
the
right
way
to
do
this
was
to
build
each
one
in
its
own
container
and
put
a
single
container
that
contains
absolutely
everything
you
need
for
Sugar
CRM
stack
next,
please
so
yeah
we
every
time
they
have
a
new
customer.
G
They
fire
off
the
scripts
up,
come
to
containers,
they
each
get
a
v6
address
and
only
a
v6
address
and
they
get
a
little
firewall.
That
says
you
can
talk
to
the
proxy
at
the
front
and
each
other
and
that's
it
and
MySQL
replicates
across
the
to
all
the
internal
traffic
is
SSH
or
SSL
based,
and
we
don't
need
a
VPN
to
connect
these
two
things
together,
even
though
they're
in
different
buildings
and
different
routing
domains
and
there's
no
layer
to
between
them,
which
is
a
massive
saving
in
networking
configuration
faff.
G
We
can
just
say
that
connections
work
go
ahead
next,
please
originally
they
built
it
internally,
built
a
prototype
and
that
you
use
docker
for
all
the
bits
and
pieces
and
sat
on
top
of
chorus
and
did
the
whole.
Oh,
my
container
has
fallen
over
automatically,
deploying
you
on
somewhere
else,
and
then
you
deal
with
the
fact
that
docker
doesn't
really
do
persistence
and
you've
got
on
MySQL
database
that
contains
your
customers
data.
G
That's
not
allowed
to
lose
more
than
a
few
seconds
worth
of
data
and
yeah
just
far
far
simpler
to
just
spin
up
a
full
stack
for
each
user
and
give
it
a
v6
address
and
assume
that
networking
works
and
you
don't
need
overlay
networks
and
you
can
use
SSL
everywhere,
so
yeah
way
way
simpler
and
less
good
news.
Hadoop
Hadoop
doesn't
work
v6
only
its
improved.
It
used
to
be
the
case.
It
didn't
work.
G
If
you
had
a
link
local
address
on
your
machine
and
the
install
instructions
told
you
to
fiddle
sysctl
to
turn
v6
off
entirely
before
it
would
start
up,
and
so
it's
improved
and
but
yeah
we've
not
yet
put
enough
work
in
to
try
and
make
her
do
work
v6
only
I'm
told
Facebook.
Have
it
all
fine
on
their
internal
infrastructure,
but
the
code
isn't
yet
public
I've
not
looked
at
this
for
a
while
I
may
be
out
of
date,
but
we
have
considered.
Actually,
maybe
the
really
hacky
way
to
do.
G
This
is
to
put
a
v4
and
v6
tunnel
for
some
RFC
1918
space
and
deploy
a
complete
set
of
forwarding
routes
to
every
machine
and
but
to
be
honest
at
a
moment,
I
have
too
many
other
things
to
do
to
really
worry
about
hadeep.
So
next
one
please
so
shag,
web-hosting
joshua
is
16
years
old
and
he
started
a
free
service
called
griddle
co
uk
to
give
free
web
hosting
to
school
kids
to
try
and
teach
them
all
about.
The
internet.
G
He's
got
I,
think
a
couple
of
thousand
and
users
now
and
he
came
to
us
and
said
my
free
trial
on
generic
cloud
service
of
choice
has
exceeded
and
they're
going
to
build
me
lots
of
money.
Would
you
like
to
support
this
because
you
support
raspberry
pie-
and
we
said
yes,
yes,
we'd,
like
to
support
that.
We
think
that's
great
have
a
bunch
of
VMs.
You
can't
have
a
v4
address
and
this
is
an
educational
project.
G
This
is
how
the
internet
is
going
to
be
learn,
and
so
yeah
we've
got
well
over
a
thousand
customers
on
that
school-aged
children
who
are
already
deploying
things
to
v6
only
land
where
v4
doesn't
exist,
they're,
kids
and
they're
ahead
of
many
people,
you
find
a
conferences
and
their
children.
Okay,
be
scared
for
people's
jobs.
Okay!
Next,
please
and
so
I
showed
you
earlier
the
picture
of
the
PI
zero.
That's
the
cheap
one.
G
This
is
the
really
expensive
model,
the
Raspberry
Pi
in
there,
each
one
of
them
cost
$35,
so
they
are
more
expensive
than
ipv4
addresses
and
are
probably
going
to
remain
that
way
for
at
least
another
six
months.
Basically,
that
is
what
we
call
our
PI
rack.
So
we've
deployed
Raspberry
Pi
attached
to
a
power
over
ethernet
device.
As
you
can
see,
they
stick
set
three
deep.
You
get
them
too
high
in
3u
of
Rackspace.
G
You
can
put
two
of
them
in
backs
back
into
a
rack,
and
that
gives
you
108
PI's
in
for
you
of
rack
space,
including
the
power
over
ethernet
switches,
to
make
it
go
scales
up
to
a
thousand
dedicated
servers
in
a
single
rack
which
is
expensive
in
v4
space,
and
so
that's
what
we
did
and
we
thought.
How
are
we
going
to
do
this?
A
very
substantial
part
of
our
cost
is
the
v4
addressing
next,
please
and
yeah.
It
looks
pretty
nice.
It's
a
couple
of
watts.
G
G
Apart
from
the
fact
it
doesn't
work
and
basically
the
boot
ROM
is
the
new
PI
has
a
much
better
boot
ROM,
the
old
one
that
was
available
has
a
number
of
really
good
features,
which
is
it
says,
I'm
a
Raspberry
Pi
here
is
my
DHCP
request.
Please
give
me
the
answers
I'm
expecting
and
if
you
deliver
it
any
packets
other
than
the
answer
it
crashes,
so
that
didn't
work
very
well
at
all
as
an
idea.
So
every
single
Pi
has
its
own
VLAN.
G
In
order
that
we
can
guarantee,
it
will
not
see
any
packet
other
than
the
one
it's
expecting
in
his
boot
process
and
if
we
want
to
give
address
place
to
every
VLAN
we're
looking
at
slash
30
of
space,
which
is
for
IP
addresses,
which
is
now
oh
sorry,
$100
of
v4
spaces
to
switch
on
a
$35
computer.
This
is
nuts,
so
next,
please
we
could
do
31.
We
could
proxy
our
there's
a
whole
bunch
of
horrid
stuff.
We
could
think
about
doing.
G
Alternatively,
we
could
say
it's
an
educational
platform,
you're
getting
v6
and
live
with
it,
which
is
what
we
did.
So
when
you
one
of
these
things
turn
on
it,
gives
you
a
port
forward,
so
you
can
get
an
over
SSH
and
then
other
than
that
it
sits
behind
a
standard
proxy
service
for
all
of
your
other
services.
So
you
can
do
HTTP
another
thing
that
supports
SSL
and
again,
if
you
want
to
run
a
service
that
doesn't
support,
SSL
wakeup
support,
SSL,
don't
deploy
non
SSL
services
anymore
ever
anybody.
Thank
you
next
one,
please!
B
G
Okay,
I'm
not
sure
exactly
what
you
mean
by
customers
that
have
only
ipv4.
Do
you
mean
VMS
that
we
host
that
only
have
v4
or
because
I
mean
obviously
80%
of
the
internet
only
has
before,
but
they
can
all
use
services
on
our
v6
infrastructure
because
there's
a
proxy
in
way.
So
you
know
v4
is
never
going
to
go
away
as
far
as
I'm
concerned.
Some
people
will
never
leave
it
and
that's
okay.
G
They
can
stay
there,
but
then
I
mean
I,
mean
I,
guess
the
yeah,
the
point
up
in
making
is
I've
deployed
v6
only
because
it
solves
a
bunch
of
problems.
I
have
which
is
I
can't
grow.
My
company
and
I
don't
really
care
if
everybody
else
deploys
v6
or
not,
because
it
doesn't
matter
because
I
have
a
proxy
layer
to
interpret
the
it
just
helps
when
other
people
deploy
v6,
because
more
things
can
go
straight
through
him.
So.
G
The
vast
majority
of
unmanaged
VM,
so
people
who,
just
by
VM,
have
a
v4
address,
there's
very
few
of
those
that
have
v6
only
when
it
comes
to
our
managed
VMs.
It's
probably
less
than
half
now
have
a
v4
address,
but-
and
that's
not
strictly
true,
because
v6,
because
you're
addressing
is
free,
frees
up
your
destroyit
design
constraints.
G
So
it's
much
easier
to
deploy
more
servers
to
run
the
same
thing
so,
whereas
in
v4
land
you
might
go,
I
could
deploy
everything
on
one
machine
with
one
IP
and
then
it
will
all
work
and
as
soon
as
you
go,
oh
I
want
to
have
five
machines
and
micro-service.
My
things
out
is
suddenly
I've
got
to
build
a
private
address
space,
whereas
in
v6
that's
not
a
cost.
It's
not
a
time
cost.
So
it's
much
easier
to
deploy
more
things
that
a
v6
only
than
it
is
with
v4
but
yeah.
G
It's
probably
around
half
of
our
managed
services
have
a
v4
address.
Still
and
I.
Don't
know
what
fraction
of
those
we
could
persuade
to
throw
them
away,
but
probably
a
fair
few
I
mean
you
know
a
bunch
of
those
services
date
back
to
before
we
deployed
v6
at
all
and
all
that
so
there's
obviously
history
and
legacy
of
new
stuff.
We
roll
out
I,
would
imagine
yeah
I
think
it's
around
half
I.
H
Leave
our
thank
you
very
much
for
doing
this.
I've
been
wanting
to
see
more
of
this
more
about
specifically
mythic
beasts
for
three
years,
I
mean
how
much
of
you
so
there's
some
custom
code
that
you've
had
the
right
so
for
your
provisioning
systems,
for
instance,
how
much
of
that
have
you
made
available
as
open
source
and
how
much
of
it
is
proprietary.
G
So
the
stuff
that
runs
our
network
is
proprietary,
essentially,
that
only
only
exists
for
us
and
probably
take
a
bunch
of
scrubbing
before
we'd
be
prepared
to
release
all
of
it.
Increasingly,
we
try
and
turn
things
into
API
s--
that
that
people
can
use
and
and
I
mean
I'm,
not
actually
certain.
All
of
our
decisions
were
that
smart
at
the
time
we
made
them
either.
G
So
we
spent
a
lot
of
time,
and
so
one
of
the
things
you
can
do
with
our
VMs
is
you
can
beat
off
your
own,
install
media
and
for
a
long
time
that's
what
we
did
and
one
of
the
worst
things
we've
discovered
is
whilst
operating
system
support.
V6
is
quite
good.
The
installer
support
is
for
rific
yeah,
so,
and
so
that,
particularly
so,
if
you've
up
your
slack
Network,
it
works
fine,
but
we
can't
deploy
that
in
the
datacenter,
because
it
gives
everyone
an
address.
G
If
you
do
the
HP
six
by
default,
it
won't
pick
up
rusev
versus
months.
You
don't
get
races,
but
you
can
hand
it
again,
but
the
Gateway
has
to
be
in
the
same
64
is
that
the
HP
six
server,
which
means
our
Rita,
has
to
have
undress
that
matches
every
single
server
we
deploy,
and
that's
just
ridiculous
and
really
what
we
want
to
do
is.
Is
it
handy?
Were
a
/
64
of
your
own
with
gateway
address,
that's
outside
of
it,
that
you
get
a
static
route
and
explaining
that
to
a
DHCP
server?
I
Thanks
for
presenting
in
such
detail,
it
really
shows
that
sort
of
most
stuff
just
works
at
this
point.
Most
stuff
I
wanted
to
go
back
to
your
point
ray
say
it's
depressing
that
you
know.
The
only
reason
to
do
this
is
that
that's
so
bad
I
think
that's
not
depressing
I
think
that's
just
the
way
it
is
and
I
think
what
you're
doing
is
you're,
showing
that
there
is
in
fact
a
cost
difference,
and
that's
really
the
only
thing
that
matters
it
costs
money
to
do
before.
It's
not
really
necessary
for
most
use
cases
anymore.
I
A
A
A
A
A
He
has
asked
for
text
regarding
how
the
scoping
should
be
done
and
he
hasn't
gotten
something
that
works
for
him
can.
So
he
feels
a
little
bit
stuck
in
that
regard.
He's
also
gotten
comments
that
are
pretty
negative,
that
they
don't
think
the
things
should
be
a
current
draft.
So
his
question
at
the
moment
is
whether
he
should
simply
withdraw
the
draft
or
you
know
is:
is
there
more?
K
Barber
stark
so
I
actually
think
it
really
is
for
me
about
the
scoping
and
I
proposed
some
scopes,
which
apparently
he
was
not
happy
with
what
I
would
like
is
if
Russ
were
to
specifically
say
which
routers
he
has
a
problem
where
he
needs
to
solve.
That
is
scope
it
to
the
set
of
routers
that
he
specifically
wants
to
solve.
K
I
Learn
is
a
good
idea
to
same
thing,
really
I
mean
I.
Think,
like
realistically,
every
previous
six
implementations
capable
forwarding
packets
so
like
this
thing
applies
to
basically
billions
of
nodes
and
like
having
a
one-size-fits-all
thing.
Just
doesn't
work,
I,
think
yeah,
so
the
the
ITF
doesn't
really
do
shopping
lists,
and-
and
you
know
this
is
kind
of
a
shopping
this
document
and
but
but
I.
Think
if
you
want
to
do
a
shopping
list,
you
need
to
like
decide
what
you
want.
I
You
know
what
it's
an
enterprise
ribbon
or
it's
a
back
burner
and
if
we,
you
know,
put
in
some
categories
and
say:
look
you
know
this
is
this?
Is
you
know
these
requirements
are
common
to
everything
right?
You
know
you
need
to
be
able
to
forward
packets.
Okay,
you
need
to
be
able
to
send
ICMP
packet
to
Biggs,
okay
right
that
those
are
common
requirements
there
in
the
RFC's.
But
you
know
that's
fine.
I
We
can
say
this
is
necessary
for
stuff
to
work
when
you,
when
you
go
in
and
say
well,
these
are
optional
things
that
aren't
required
by
Stanley's
chart
RFC's
they're,
not
in
the
node
requirements,
which
again
like.
What's
the
duplication
between
this
and
then
a
requirements
document,
it's
not
really
clear,
but
let's
say
that
there
are
things
that
are
optional
they're,
not
in
the
node
requirements.
Then
you
say:
you've
got
you
have
to
have
a
cat.
You
have
to
have
some
categories
of
things
where
you
can
say
well
for
Enterprise
Reuters.
I
You
need
to
do
this
and
for
you
know,
you
know
portable
Reuters.
You
need
to
do
that
and
for
a
sort
of
home
Reuters.
You
need
to
do
that.
We
already
have
one
for
home
Buddha's.
It's
called.
You
know,
seven,
zero,
eight,
four
right,
we're
pretty
happy
with
that.
That's
not
a
shopping
list,
though
it's
worth
looking
at
it's
worth,
noticing
that
that's
actually
written
in
the
sense
most
of
the
requirements
ends
you're
right
for
our.
I
If
you
do
this,
then
you
must
do
that
they're,
not
of
the
form
you
have
to
do
this
this
this
and
this
and
every
time
someone's
tried
to
propose.
Oh,
you
need
to
be
able
to
do
DS
Lite,
and
you
need
to
be
able
to
do
security
and
things
like
that.
Those
attempts
of
foundered
so,
like
I,
said
the
only
ideas
here
were
to
define
some
profiles
and
see.
If
we
can
get
consensus
on
the
sub
profiles,
you
know
we
can
probably
steer
clear
of
most
of
the
contentious
points
and
say:
well,
you
know.
I
Maybe
no
one's
gonna
disagree
with
Enterprise
Rooter
requirements.
Maybe
that's
gonna
be
fine,
but
just
having
one
one
size
fits
all
I,
don't
think
it's
ever
gonna
fly
oh
and
add
to
e.
We
had
this
problem
with
the
mobile
device,
node
requirements,
and
that
was
pretty
painful
and
long.
It
took
a
long
time
for
that
to
fail
and
I,
don't
think
that's
in
anyone's
interest
right
to
do
it
again.
L
Jim
Jones,
oh
I,
think
I
agree
with
pretty
much
everything.
Lorenzo
said
the
co-author
of
see
a
slightly
different
shopping
list,
the
64
34
base.
There
are
a
number
of
things
in
there
that
do
apply
to
all
nodes,
but
we
do
have
essentially
a
quite
a
few
if
thenns
in
there
as
well,
that
are
conditional
on
the
context.
Also
64
34
based,
doesn't
stray
too
much
into
Ruta
territory.
It's
largely
about
coasts
as
nodes,
rather
than
rooters,
and
are
in
our
minds.
This
document
is
kind
of
in
some
ways.
L
Complimentary
to
that,
and
it's
talking
more
about
the
route
inside.
In
fact,
we
did
do
a
consistency,
check,
I,
think
Lorenzo
hinted
at
how
consistent
the
two
are
there
and
we
found
maybe
seven
or
eight
differences
and
we've
brought
them
together
all
but
a
couple
of
those
things
by
changing
one
or
the
other,
so
I
think
in
terms
of
what's
stated
in
them.
They
are
pretty
consistent.
The
only
one
that
isn't
consistent,
which
I
guess
Lorenzo
will
love
is
the
crucial
one
says,
must
do
dhcpv6
and
the
hosts
one
says
should
do
dhcpv6.
L
So
that's
the
the
one
discrepancy
there.
I
think
in
terms
of
the
document
itself,
I
really
like
the
way
the
documents
written
the
routier
requirements,
I
think
the
first
two
or
three
sections
I,
don't
remember
the
exact
structure
or
a
really
nice
discussion
of
some
of
the
things
you
should
be
thinking
about.
L
If
you're
deploying
these
things
and
I
think
that's
really
excellent
stuff
to
take
forward
I
think,
obviously
we
can
have
comments
about
whether
the
rest
of
it
applies
to
selective,
selective
deployment
scenarios
or
not,
but
I
would
hate
to
think
the
whole
thing's
thrown
away
with
all
that
other
good
material
in
there.
Just
because
of
the
weather,
we
can't
agree
to
set
a
context
or
not.
L
A
M
A
M
A
F
Yeah
so
since
last
idea,
I
made
some
changes,
so
I
added
the
section
about
what
to
do
if
up
links
of
Philippian,
because
obviously
it
would
be
probably
good
idea
of
duplicate
and
unduplicated
the
prefixes.
Every
time
a
plane
goes
down,
so
probably
something
similar
to
a
BGP,
Lemkin
I
should
be
implemented
and
I
fixed.
Some
typos
and
they--but
clarified
the
situation
with
inter-site
communication
in
case
of
total
uplink
failures,
so
yeah
some
system
definitely
use
preferred
ipv6
addresses
at
least
some
applications
on
some
system
a
tested.
F
Do
you
prefer
the
ipv6
address
if
it's
the
only
tv6
address
available?
So
it's
not
doing
fall
back
to
before,
but
is
there
are
some
suspicions
that
it
might
be
actual
application
dependent?
So
the
recommendation
is
if
the
seal,
if
the
side
does
require
inter-site
communication
in
case
of
multiple
uplink
trailers,
it
may
be
worse,
can
our
increasing
number
of
uplink
so
usually
so?
No
something
like
that
yeah,
but
again,
I.
Think.
The
goal
of
this
draft
is
to
provide
recommendations
for
real
small
sites.
F
We
just
need
Internet
connectivity
in
most
cases,
if
your
topologies
really
complex-
and
here
probably
it's
not
a
solution,
you
should
be
implementing
as
it
is
so.
I
have
not
received
too
many
comments.
Since
the
last
update,
and
so
I
would
like
to
ask
working
group
any
suggestions
to
improve
comments,
or
maybe
shall
we
tried
a
lot
cool
because
I
know
people
normally
reads
draft
when
in
the
last
call
and
I
really
want
you
to
read
this
draft.
A
A
L
You
Jim,
Joe
and
so
I
read
this
and
I
think
it's
it's
some
of
the
improvements
you
made
a
good
I
think
it
was
good
in
its
previous
state,
so
I
very
much
like
to
see
it
advance.
I.
Think
it's
very
useful.
You
hear
a
lot
of
comments
from
people
that
want
to
do
sort
of
tiny
networked
multihoming
that
there
are
things
that
just
don't
work
and
having
this
quite
practical
advice,
I
think,
is
really
useful.
L
F
Think
there
multi-home
co-star
of
she
already
saying
the
cost
sheet
track.
This
information,
yes
or
I-
think
Ruth
is
good
enough.
But
again
this
drop
this
particular
draft,
not
the
big
one,
which
is
50
pages
long
and
the
writing
working
group
right.
It's
something
which
documents
current
solution,
which
I
can
deploy
right
now
right
here,
right
yeah.
So
if
I.
L
F
N
N
F
L
L
I
I
yeah
joe:
let
go
for
girl
for
law
school
ship
that
get
it
done.
I
am
the
only
thing
that
I
would
I
would
add
to
document
if
possible,
but
don't
hold
it
up
for
that
as
to
is
to
explain
how
this
is
basically
equivalent
to
ipv4
plus,
not
because
base
I.
Think
I
think
the
failure
modes
are
either
exactly
identical
or
pretty
much
almost
the
same,
and
so
it's
true
that
this
doesn't
do
perfect
multihoming,
but
neither
does
not
right
and.
F
F
I
F
I
I
I
think
the
goal
of
this
was
to
say
look.
You
know
this
is
actually
possible
today.
If
the
network
supports
it,
you
know,
and
and
just
another
thing
about
this
sort
of
5.5,
the
the
I
think
the
I
can't
remember-
I
mean
I
K.
This
is
swapped
out
in
my
memory,
but
I
think
we
talked
about
that
a
long
time
ago.
You
actually
you
and
I
Jen
about
whether,
if
I
bought
five
would
be
needed
to
be
a
must.
I
I
F
I
Yes,
so
that
was,
it
goes
basically
for
we're
doing
right
exactly
so.
If
we
were
doing
if
we
were
requiring
house
changes
anyway,
then
we
might
as
well
do
something
that
really
solves
the
problem,
because
5.5
s
kind
of
a
hack
anyway,
really
it
sort
of
kind
of
helps,
but
not
that
much
I
think
I
think
that's
what
we
where
I
was
ending.
L
I
L
Jim
Jones,
I
I,
think
I
agree
with
Lorenzo
said
there,
so
67
24
as
an
update,
was
probably
two
or
three
years
ago
known
at
the
time.
While
we
were
doing
that,
this
topic
came
up
and
we
thought
well.
Let's
add
this
extra
thing
in
there
to
make
things
slightly
better,
but
I
agree.
It's
not
by
no
means
perfect.
O
I'm
Jimmy,
oh
dear
first
of
all,
I
just
like
to
say,
I've
read
the
draft
and
they
didn't
find
anything
any
program,
so
I
think
it's
basically
ready
for
Roscoe
and,
secondly,
are
regarding
the
5.5,
a
restriction
rule
I'm
wondering
that
newer
implementations
may
actually
be
supporting
it,
given
that,
for
example,
a
happy
hour
version,
2
is
doing
something
quite
complicated,
so
I'll
not
be
surprised
if
there's
actually
implementation
of
it
I
understand.
Even
if
there
is,
it,
doesn't
make
the
main
point
of
this
draft,
but
I'm
just
wondering.
O
P
P
A
Thanks
Jim,
so
I'll
open
up
a
last
call
on
the
list
Polly
starting
this
weekend,
or
something
like
that.
When
you
comment
and
notice
the
wind
idea
I'd
like
you
to
tell
me
whether
you
think
there's
utility
and
which
is
to
say,
if
you
have
no
negative
comments,
I
still
want
a
positive
comment,
saying
that
you
know
you're
ready
to
go,
go
with
us
and
if
there's
any
issues
of
course,
I
want
want.
The
issues
raised
so
it'll
be
a
to
work
to
week.
Q
Q
Q
When
the
red
packet
counters
are
running,
the
blue
counters
are
still,
and
vice
versa.
In
this
way,
you
can
take
the
counters
in
the
in
the
following
in
marking
interval
in
order
to
have
the
number
of
packet,
the
the
previous
block.
So
in
this
way
the
packet
loss
calculation
is
very
simple
because
you
can
compare
the
number
of
packets
for
each
block
that
is
identified
by
a
color.
Also
delay
and
delay
variation
can
be
measured.
What
are
the
main
strengths
of
this
methodology?
Q
So
it
works
on
real
production
traffic,
so
there
is
no
injection
of
synthetic
traffic.
It
it
works
even
in
cause
of
auto
sequence.
In
fact,
if
you
have
reordering
at
the
edge
of
the
batch,
you
can
take
the
counter
after
a
while
in
the
following
batch.
So
you
don't
have
a
problem
of
reorder
and
it
can
work
on
not
synchronized
at
the
network,
because
the
alternate
marking
change
is
a
lot
sort
of
out
of
synchronization
signal
over
know
over
your
network.
So
you
don't
need
a
strict
synchronization
and
it
worked
without
Owen
packet.
Q
Q
Ok,
this
is
just
look
of
the
summer
fizzy
8321
application
in
ATF,
so
we
have
some
use
case
in
beer
in
general
and
a
sage
as
I
mentioned
before,
the
use
of
of
RFS
is
63
74
with
the
alternation
of
the
synonymous
flow
label
for
the
application
of
marking
method.
There
is
also
a
variation
of
the
ultimate
marking
in
quick
protocol
that
is,
the
spin
meet
application.
Q
This
does
not
work
in
case,
is
sensitive
to
packet,
loss
and
packet
ordering,
because
if
the
first
packet
of
your
batch
get
reorder
or
has
been
lost
at
the
same
packet
is
not
the
same
for
the
next
for
the
next
router.
So
you
can
have
this
kind
of
problem.
An
alternative
could
be
to
use
the
average
packet
delay
calculation
that
can
be
done
by
calculate
the
average
time
stamp
for
each
batch
and
by
comparing
the
average
theis
time
between
two
measurement
points.
You
can
calculate
the
mean
delay.
The
average
delay.
Q
We
would
suggest
to
use
the
double
mark
method,
because
is,
can
avoid
some
packet
loss
and
out
of
order
issue
that
we
have
with
single
mark
method,
because
we
use
the
air
flag
to
create
the
first
marking
batches
for
packet,
rows
calculation
and
you
use
another
flag
to
select
some
set
of
special
packet
that
are
dedicated
or
the
delay
measurement.
So
this
D
market
packet
are
full
identify
over
your
network
and
can
be
used
for
the
delay
calculation.
Q
Q
Q
What
about
the
pv6
okay,
each
of
the
layers
is,
is
responsible
of
it's
our
know
am
so
we
want
to
introduce
this
methodology
for
active
e6
because
telecom
italia.
We
experimented
this
methodology
for
ipv4.
We
want
to
experiment
it
for
AP
v6
and
we
wanted
to
understand,
together
with
the
the
working
loop,
how
we
can
apply
this
to
ipv6
scenarios,
so
we
find
some
alternatives
to
apply
the
methodology
by
using
an
extension
adder
by
using
ipv6
address
and
also
by
using
the
follow
label.
Each
of
these
alternatives
have
some
some
pros
and
cons.
Okay,.
Q
For
example,
you
won't
use
an
extension
either
to
include
the
marking
feel
we
should
could
use
an
existing
encapsulation
other
or
we
should
in
reuse,
or
we
should
define
a
new
encapsulation
either,
but
having
an
encapsulation
either
seems
to
be
expensive
because
we
need
just
one
or
two
bits
to
to
apply
this
methodology
the
same.
If
we
want
to
use
this
nation
address
to
include
to
encode
this
methodology,
so
we
can
consider
these
also
expensive
and
not
so
much
compatible
with
the
existing
application,
the
other.
The
other
suggestion
is
to
use
the
flow
level
field.
Q
Q
We
got
some
discussion
on
Bozzio
PS
mini
list:
okay,
okay,
there
are
some
points
of
discussion
that
were
raised,
for
example
regarding
the
flow
level
application.
If
we
want
use,
1
or
2
beats,
does
18
or
19
beats
in
a
be
enough
for
the
entropy.
So
this
is
a
first
question
that
we
should
Astrid
address.
Called
the
flow
label
be
overloaded
so
because
it
will
be
used,
but
for
marking
for
BOTS,
for
IOM
and
for
entropy
and
for
load
balancing.
Q
So
these
can
be
also
reused
in
any
v6
scenarios,
and
the
other
point
was
about
the
the
intended
status
of
this
draft
that
can
be
standard,
informational
or
or
experimental.
So
there
is
some
discussions
about
this
as
a
next
step,
and
we
want
to
find
an
agreed
solution
for
the
application
of
this
methodology.
We
want
to
add
a
multi-point
use
case
that
is
a
it's
a
world
working
process
also
in
a
PBM.
We
want
to
extend
also
to
ipv6
scenario.
Okay
and
question
and
comment
are
welcome.
A
Q
A
A
L
L
So
again,
just
for
the
context
of
what
we're
discussing
here
and
I
think
yo
and
in
six-man
the
obvious
concerns
will
be
that
the
revised
flow
label
spec
says
I,
think
you
can
only
set
the
flow
label
to
a
essentially
a
random
flow
value
if
it
arrives
with
a
zero
value,
so
I
suspect
lots
of
hosts
are
already
setting
flow
labels.
So
your
ability
to
remark
that
may
be
limited
and
then
there's
the
obvious
extension
header
insertion
questions
that
will
happen
with
the
camera
yeah
in
principle.
H
Lee
Howard,
as
co-chair
part
of
the
operational
question
I
think
is:
is
this
interesting
work
that
would
be
operationally
useful?
Are
there
operators
who
would
who
would
implement
it
if
this
was
if
the
alternative
marketing
method
was
available
somewhere
in
a
packet?
If
there
are
people
who
think
that
would
be
interesting
and
I've
heard
of
use
cases,
but
I
haven't
heard
of
anybody
saying
yes,
I
would
like
to
measure
my
network
or
measure
my
my
performance
in
that
way,
and
that
could
be
that
doesn't
have
to
be
network
operators
that
could
be
endpoint.
R
Thanks
to
the
lead-in
me
I'm,
not
quite
quick
enough
as
an
enterprise
operator.
Yes,
now
the
devil
may
be
in
the
details
and
you're
sitting
right
in
front
of
me.
So
I'm
going
to
talk
to
you
more
about
this
later
about
how
we
would
implement
it.
That
would
make
a
big
difference
to
me
and
that,
but
the
the
general
capability
of
this
information
would
be
very
valuable
to
manage
our
networks.
A
H
D
A
E
Ron
Bonica
Atlas
penniless,
the
title
of
this
draft
is
IP.
Fragmentation
considered
fragile.
It
used
to
be
entitled,
ipv6
fragmentation
considered
fragile,
but
one
of
the
co-authors
Bob
Hendon
pointed
out
that
most
of
the
criticisms
we
raised
against
ipv6
fragmentation
are
equally
applicable
to
ipv4,
so
we
made
it
slightly
more
general.
E
So
what
do
we
here
for
today?
First
is
to
point
out
that
fragmentation
is
a
bit
fragile
talk
about
how
fragmentation
works,
why
it's
fragile
and
then
come
up
with
some
recommendations.
Now
about
six
years
ago,
I
wrote
a
draft
recommending
that
we
deprecated
fragmentation,
we're
not
trying
to
do
that
today.
We
can't
deprecated
fragmentation,
but
what
we
would
like
to
do
is
point
out
the
problems
and
encourage
protocol
developers
to
wean
themselves
off
their
dependence
on
fragmentation,
make
them
use
it
less
and
less
and
less
so.
The
problems
will
be
less
and
less
evident.
E
It's
not
about
deprecation.
It's
about
weaning,
the
community
off
of
fragmentation.
So
there
couple
terms
that
we
need
to
know
before
we
can
even
have
the
conversation
we
need
to
know
what
MTU
is.
We
need
to
know
what
the
minimum
link
MTU.
Is.
Everybody
knows
for
ipv6,
it's
1280.
Everybody
has
probably
shocked
that
for
ipv4
it's
only
68,
it's
not
576.
E
E
The
big
difference
between
them
is
in
ipv4.
You
can
fragment
at
the
source
always
or
if
the
DF
bit
is
clear,
you
can
fragment
downstream
and
ipv6.
You
can
only
fragment
at
the
source.
There
is
no
DF
bet,
and
if
it
were
there,
it
would
be
assumed
to
be
clear
all
the
time.
There
is
one
thing:
what
well
yeah
sorry
I
said
all
the
time
jet
lag.
E
There
is
one
thing
that
ipv4
and
ipv6
fragmentation
have
in
common.
When
you
get
a
packet
and
you
fragment
it,
you'll
see
the
upper
layer
header
in
the
first
fragment
all
of
the
time
always
for
every
fragment.
You
will
never
see
the
upper
layer
header
in
the
second
through
went,
fragments,
you'll,
never
see
it
in
the
subsequent
fragments.
E
E
First,
it
has
to
be
one
option
as
it
can
be
really
conservative
and
never
send
a
packet
bigger
than
the
minimum
link
MTU.
That
way
it
will
never
have
to
fragment.
That's
one
thing
you
can
do
in
ipv6
or
an
ipv4
when
don't
fragment
this
set.
Another
thing
you
can
do
is
let
the
IP
layer
keep
track
of
what
it
thinks.
The
path
MTU
is
and
try
to
stay
beneath
that.
That's
the
PM
tud
discussion
which
we'll
have
in
this
slide.
E
E
The
source
makes
an
initial
estimate
of
what
the
PM
t
you
to
a
destination
is
generally.
That
estimate
is
the
MTU
of
the
first
top
towards
the
destination.
That
estimate
may
be
large,
but
it's
the
best
you
can
do
a
priori.
Then
the
source
starts
sending
packets
and
one
of
those
packets
is
going
to
be
too
large.
When
that
happens,
the
router
that
had
a
hard
time
forwarding
sends
the
an
ICMP
packet
too
big
back
upstream.
The
PTB
message
has
the
MTU
of
the
link
you
could
not
forward
through
the
source
receives
the
ICMP
message.
E
E
Okay,
there
was
another
option.
If
you
don't
want
to
rely
on
PM,
tud
and
those
ICMP
messages,
another
possibility
is
packetization
layer,
P,
MTU
discovery.
In
this
case
an
upper
layer
protocol,
say
TCP
starts
out.
It
makes
an
initial
estimate
of
what
the
PMT.
U
is,
then
it
starts
sending
probe
packets
to
its
TCP
peer
of
various
sizes,
so
it's
padding
the
packet,
so
it'll
be
bigger
or
smaller,
and
it
discovers
the
PM
to
you
that
way
and
every
once
in
a
while.
E
Essentially
what
it's
doing
is
pushing
the
problem
of
PM
tu
discovery
up
to
the
packetization
layer
and
rather
than
relying
on
it--.
Well,
it
can
use
ICMP
feedback
if
it
wants
to
look.
It's
basic
feedback
is
acknowledgments
of
its
own
probe,
probe
packets.
So
we
kind
of
know
the
state
of
the
world.
Now
so
I
said,
IP
fragmentation
makes
as
fragile.
Why
did
I
say
that.
E
If
you
go
back
to
that
first
slide,
the
transport
layer,
header,
is
only
in
the
first
fragment
this
messes
up
a
few
things.
The
first
thing
it
messes
up
is
a
load
balancer
many
load
balancers
try
to
load
balance
on
things
that
are
in
the
transport
layer,
header
and
if
they're,
not
there,
you
just
can't
load
balances
effectively.
Another
possibility
is
firewalls.
A
firewall
filter
may
filter,
based
on
something
like
a
TCP
port.
E
If
you're
a
stateless
filter,
a
filter,
you're
not
reassembling
the
packet,
you
can
configure
your
firewall
filter
in
one
of
two
ways,
too
permissive
or
too
restrictive.
Either
way
you
go,
you
have
a
problem:
either
you
let
in
every
subsequent
fragment,
which
is
too
permissive
or
you
don't
let
any
of
them
in
which
is
too
restrictive.
Then
there
are
other
metal
boxes
that
have
the
same
problem.
Let's
say
your
middle
box
is
trying
to
say,
update
a
diffserv
code
point
based
on
the
TCP
port.
Well,
how
do
you
do
that?
E
Hello,
oh
there
we
go
okay.
Now
there
were
also
some
well-known
security
vulnerabilities
around
IP
fragmentation
and
they've
been
documented
for
years.
One
of
them
is
the
overlapping
fragment
problem
you
send
to
fragments
they
overlap.
Looked
at
individually.
They
passed
the
security
policy,
but
when
you
reassemble
the
packet
one
fragment
over,
writes
another,
and
you
have
something
that
wouldn't
have
passed
the
policy.
E
Yes,
you
can
prevent
that
by
reassembling
correctly
and
there
are
FCS
that
talked
about
how
the
correct
reassembly
should
be
done,
but
the
firewall
can't
help
you
with
it
you're,
relying
entirely
on
the
host.
That's
doing
the
reassembly,
the
resource
exhaustion
attacks
like
the
ROS
attack.
We
all
know
about
those
things.
E
Another
interesting
problem
is
black
holing
due
to
ICMP
loss
and
I,
see
Jeff
Jeff
Austin
just
walked
in
he
pointed
out.
There
are
a
couple
reasons
for
a
black
holding
during
due
to
ICMP
loss.
One
is
just
somebody
filtered
ICMP
and
that's
a
bad
thing.
They
shouldn't
they're
RFC's.
That
say
they
shouldn't,
but
there
are
problems
times
when
you
have
the
problem
and
you
can't
prevent
it.
For
instance,
let's
say
for
a
moment
that
I'm,
a
DNS,
client
and
I
send
a
DNS
request
to
a
server
and
I,
send
it
to
an
anycast
address.
E
It
goes
through
just
fine.
The
server
responds
with
a
great
big
response
and
its
source
address
is
in
any
cast.
It
has
a
PM
tu
problem
and
it's
relying
on
an
ICMP
message.
An
ICMP
message
gets
sent
to
the
anycast
addressed
and
unfortunately,
it's
delivered
to
a
different
DNS
server
than
the
one
who
sent
me
the
packet
black
hole
time.
E
E
E
Dcs
man
I'll
get
it
right.
There's
a
draught
Fairhurst,
that's
working
in
the
TSP
working
group.
That's
hitting
a
bunch
of
other
protocols!
I
hear
that
there
is
another
draft
in
TSV
talking
about
a
way
to
do
fragmentation
at
the
UDP
level,
so
your
UDP
will
be
able
to
fragment
and
won't
really
rely
on
IP
fragmentation.
All
that
stuff
is
good,
and
this
draft
is
encouraging
that,
if
not,
you
know,
if
not
mandating
it.
E
Quick,
thank
you.
So
what
are
some
recommendations
here?
Well,
first,
is
applicant
application
developers
should
not
develop
new
protocols
that
rely
on
IP
fragmentation
if
you
develop
them,
they're
not
going
to
work
in
all
environments.
Second,
this
is
just
a
repetition
of
another
RFC
operators
should
not
filter
ICMP
packet
to
bigs
notice.
I
do
not
say
that
operators
should
not
filter
fragments;
they
do
that
now
and
they
probably
do
it
for
very
valid
reasons.
E
I
just
stay
away
that
point
altogether
and
the
meta
recommendation
here
is
that
DNS,
particularly
when
DNS
SEC
is
involved
in
you're,
sending
long
responses
that
needs
a
solution.
It's
it's
critical
to
the
internet
architecture
that
DNS
doesn't
hit
the
fragility
that
IP
fragmentation
causes.
Now
the
next
slide,
I'd
like
you
to
ignore.
E
B
Line
and
I'm
actually
going
first
Michael
Abrahamson,
so
the
network
operator
of
recommendation
I
think
it
should
actually
say
you
must
configure
a
network
to
make
path.
Mtu
discovery
work.
That
recommendation
is
not
strong
enough
when
it
comes
to,
because
there
are
plenty
of
scenarios
where
no
ICMP
sit
never
is
ever
generated
at
all.
It's
not
about
filtering
it.
It's
there.
B
S
George
we
have
an
elephant,
the
room,
it
continues
to
be
an
elephant
and
it
continues
to
not
get
discussed
but
saying
that
we
shouldn't
develop
applications
that
rely
on
IP.
Fragmentation
is
kind
of
the
tail
wagging
the
dog
in
that.
The
real
problem
here
is
that
we
can't
carry
packets
that
are
big
enough
because
we
still
don't
have
an
MTU
larger
than
1500.
Officially,
yes,
we've
got
plenty
of
places
we
can
do
jumbo
frame,
but
we
are
technically
in
violation
of
the
ethernet
spec.
S
When
we
do
that,
and
while
I
am
NOT
suggesting
that
any
sort
of
formal
change
there
will
actually
fix
the
MTU
problem,
it
will
help
to
reduce
the
area's
we're
using
larger
than
lowest-common-denominator
MTU
might
actually
work,
because
it
will
be
more
consistently
supported.
So
I'd
like
to
recommend
once
again
and
again,
this
is
something
that
isn't
specific
to
this
working
group.
S
But
given
that
you're
talking
about
taking
this
draft
to
a
larger
discussion
anyway,
there
might
need
to
actually
be
the
liaison
statement
to
I
Triple
E,
saying
please
to
fix
this
again,
but
still
the
rest
of
the
world
has
moved
on
without
you
you'd
at
least,
maybe
make
it
official
so
that
we
can
make
this
work
better.
Because
that's
the
fundamental
problem
here,
okay,
I,
agree.
N
Jared
much
Akamai,
so
I
had
one
comment
and
then
Wes
stuck
his
second
one
in
my
brain
so
but
I'll
try
and
stick
to
my
first
one.
So
the
the
reason
why
I
have
often
seen
many
fragments
on
the
internet
and
I've
seen
people
filter,
fragments
on
the
Internet
is
primarily
around
UDP
amplification
reflection
attacks.
E
N
E
F
F
F
Secondly,
as
an
operator
I
filter
packets,
which
I
do
not
need
and
if
I
need
DNS
I
would
happen
not
to
filter
DNS
right
so
I
believe
maybe
it
would
be
nice
recommendation
to
say
network
operators
that
might
they
might
consider
not
filtering
fragments
to
and
from
the
DNS
servers.
Well,
how
would
you,
okay?
Okay,
it's.
F
Scenarios
when
some
networks
have
their
own
DNS
servers
a
clients
Union
right,
and
they
know
what
those
addresses
are.
It
would
not
completely
fix
the
problem,
but
it
fixed
part
of
it
for
a
significant
number
of
users.
So
I
think
it
might
be
nice
recommendations.
They
are
not
just
okay,
because,
honestly,
the
main
problem
is
Danis
right,
I
do
not
care
about
our
SPF
SPF
israelian
within
the
network.
I,
normally
control,
MTU
and,
to
be
honest,
I
have
never
seen
my.
E
F
P
Giulia
scrubber
track.
So
thanks.
Thank
you
very
much.
So,
as
you
mentioned,
you
repeat
a
few
things
that
are
in
other
RFC's
and
another
documents,
but
that
could
be
a
very
helpful
document
because
we
keep
seeing
people
who
rely
on
fragmentation
and
their
protocols.
It
would
be
very
helpful
to
have
a
document
that
you
can
show
and
tell
people
look
I'm,
not
going
to
explain
it
to
you,
because
some
wiser
people
than
we
have
explained
it
very
well
in
this
document,
so
I
think
it's
a
very
good
idea.
P
I
do
have
some
editorial
comments,
so
one
is
that
I'm,
not
quite
sure.
So
perhaps
the
least
important
one
is
I
think
you
don't
insist
enough
on
the
issue
of
efficiency
on
what
happens
when
some
packets,
some
fragments
are
destroyed
by
nake
and
others
are
not
so
they
become
useless.
I,
don't
think
it's
a
significant
problem,
but
it's
something
that
speaks
to
people's
imagination,
so.
P
Be
worth
stressing
that
a
little
bit
more
and
the
other
point
is
I,
have
the
feeling
that
it's
not
quite
clear
who
you're
speaking
to
are
you
speaking
to
network
operators
or
to
application
programmers
and
what
I'm
concerned
about
our
application.
Programmers,
because
I
think
that
network
operators
are
very
wise
people
and
they
don't
have
this
problem
of
going.
P
So
I
would
like
to
see
it
more
aimed
at
application.
Programmers
and
I
would
like
you
to
say
outright
from
the
beginning,
look
mate
if
you're
doing
TCP
you're
fine,
because
TCP
will
do
it
for
you.
But
if
you're
layering
your
application
layer
protocol
over
UDP,
then
it's
your
duty
and
you
will
burn
in
hell.
If
you
don't
think,
are
a
particular
problem
to
be.
F
E
P
J
J
They
arrive
before
so
we
had.
We
are
doing
that
doing
a
quick,
interrupt
test
and
doing
the
quick
in
table
test.
One
of
my
colleagues
with
whom
I
was
trying
to
interpret.
There's
me
hey.
Why
are
you
sending
the
encrypted
packet
before
the
uncheck
finished
packet,
because
I
mean
the
encryption
key
is
in
the
uncheck
finished
packet
and
then
you
send
encrypted
packets
yeah.
That's.
J
J
That's
one
of
the
thing
that
you
might
want
to
mention
there
and
then
they
are
also
the
fact
that
guys
that
meters,
it's
worth
to
say
that
application
layer
providers
shall
not
depend
on
ipv6
fragmentation.
We
don't
in
fact
we
want
one
too,
but
have
you
observed
that
there
is
no
such
thing
as
an
ipv6?
Don't
one
bit
in
the
header
it's
on
by
default,
a
choice.
E
J
A
L
After
years
of
observing
the
lack
of
success
of
BC
p-38
I
actually
think
that
there
is
not
much
hope
in
trying
to
fix
structurally
broken
problems.
There
is
no
doubt
right
now
in
the
v6
Network
the
chances
of
getting
a
fragmented
packet
through
the
network,
for
whatever
reason
it
got
fragmented
to
any
arbitrary
destination.
Your
chances
are
about
60
percent
success
rate
and
in
v4
your
chances
are
still
only
at
80%
I,
don't
think
we
can
fix
it.
There's
empirical
evidence
to
support
that.
L
So
all
the
whips
in
the
world,
all
the
castigation
and
so
on,
won't
fix
it.
So
what
does
that
mean
for
TCP?
As
you
said,
a
good
TCP
will
actually
try
and
work
within
parameters
that
don't
require
fragmented
TCP
and
in
theory
one
should
never
see
fragmented,
TCP
packets,
certainly
in
v6,
because
it
can't
happen
on
the
fly.
You
should
never
see
it.
What
about
UDP
and
again,
someone
said
you
know
it's
the
DNS
and
that's
true,
largely
that
the
big
packets
of
DNS
and
DNS
that
go
together
now.
L
But
if
you
really
thought
god
this
is
going,
probably
not
to
make
it,
wouldn't
you
immediately
fall
back
to
TCP,
almost
at
once
in
the
application
protocol,
in
other
words,
rather
than
thinking
that
fragmentation
loss
is
a
rare
event,
and
it
will
take
me
some
time
to
test
shouldn't.
You
immediately
say
well,
I'm
going
to
send
a
fragmented
packet,
but
then
I'm
going
to
trigger
the
dns
to
go
to
TCP
as
soon
as
I
can
and
so
over
in
DNS
ops.
L
In
theory,
they
should
be
looking
at
a
draft
by
Davy
song
that
suggested
whenever
you
fragment,
send
an
additional
gratuitous
response
packet.
That
is
your
question
with
the
truncate
bit
set.
If
you
don't
get
the
frag
within
a
couple
of
milliseconds
you'll,
get
the
trigger
to
go
to
TCP
and
avoid
the
fragmentation
problem
I
like
that
thinking,
because
once
you
get
to
the
room
of
it,
ain't
going
to
ever
get
fixed.
Let's
live
with
this!
L
E
L
E
H
A
N
Jared
montz
from
Akamai
again
so
I
I
have
a
kind
of
similar
theme
of
of
what
Jeff
was
talking
about,
which
is
that
and-
and
you
know,
West
brought
up
earlier
of-
let's
just
make
really
large
him
to
use
really
large,
mr
use
on
the
internet.
So
we
can
pass
all
these
really
large
packets.
The
problems
that
that
I've
seen
here
are
that
the
router
vendors
tend
to
do
this
very
poorly
in
in
stuff.
N
We
we
have
the
we
have
the
rate
limiters
that
you
know
we're
previously
mentioned
as
well,
that
go
and
cause
these
packets
to
not
necessarily
be
generated
back.
So
the
hosts
understand,
what's
going
on,
but
I
have
to
say
most
importantly,
the
end
users
and
the
performance
expectations
that
they
have
in
running
a
CDN
our
end
users.
Our
end
customers
have
really
high
performance
expectations.
The
the
extra
a
couple
RT
t
to
go
into
a
p.m.
tu
event
is
something
that.
F
F
N
You
know
because
some
of
these
switches,
misconfigured
wrong
or
routers
it
was
configured
wrong,
is
really
something
that
is
going
that
many
people
are.
You
know,
advanced
operators
are
going
to
find,
but
many
of
the
less
sophisticated
operators
are
gonna
have
a
huge
time
debugging
that
yeah
that's
a
big
concern.
I.
E
Think
between
you
and
Jeff,
what
we've
just
figured
out
is
that
we
need
more
nuance
to
that
recommendation
to
application
developers.
Just
saying
don't
do
it
isn't
good
enough?
That's,
like
you
know,
just
say
no
to
drugs.
We
have
to
say,
try
not
to
do
it.
If
you
have
to
do
it,
have
some
recovery
mechanism
and
by
the
way
the
recovery
mechanism
has
to
perform
well.
I
But
in
security
I
don't
see,
I,
don't
see
that
usefulness
in
that
guidance
said
it's
just
you
know.
If
it's
broken,
then
just
move
away
from
it
like
realistically,
realistically,
there's
really
I
think
there's
really
nothing.
We
can
practically
do
to
fix
this
problem
and
you
know
we
might
as
well
be
looking
at
packetization
later.
You
know
the
transport
layer,
solutions
for
fragmentation
right,
another,
an
extra
UDP
header
or
or
just
putting
the
solutions
into
the
protocols
that
need
them.
I
mean
like
you.
I
We
can
pretend
that,
like
you
know,
2,000
byte
packets
will
survive
on
the
Internet
factors
that
they
don't
right
so
I
mean
for
DNS
again
like
how's
that
how's
the
client
gives
the
client
it's
the
one
that
needs
to
fall
back
to
TCP
right.
How
does
it
client
know
if
the
response
is
gonna,
be
too
big?
Do
I?
Try
it
every
time
right,
cuz,
it's
yeah.
E
I
And
so
so
so
I
think
I
think
that's
actually
reasonable
guidance
is
like
basically
and
and
and
I
think
you
you
get
bitten
by
packet,
reordering
all
the
stuff.
We
just
need
to
say
look
and
but
you
know
one
thing:
you
know
that
we
got
when
we
were
implementing
for
6
for
X
site,
which
also
has
fragmentation
issues
right,
there's
like
Ike
Ike
assumes
that
you
can
send
whatever
a
certificate
in
a
packet
and
that's
just
silly
right.
I
Sorry,
oh
I
could
be
one
sorry,
ok,
so
so,
but
but
my
sure,
but
my
point
is
I-
think
even
protocol
developers
right.
We
should
stop
assuming
that
fragmentation
is
gonna
work,
yeah.
E
E
Gonna
try
to
sit
on
the
fence
without
hurting
myself.
On
the
one
hand,
we
can
make
this
more
nuanced
guidance.
On
the
other
hand,
if
we
just
leave
the
guidance
the
way
it
is,
people
who
are
actually
experts
will
fix
the
problem
and
we
need
to
find
some
Jeffrey
shaking.
Is
that
no
or
they
might
not?
So
we
need?
We
need
to
work
that
problem,
that's
probably
for
the
mailing
list,
I'm.
O
Jimmy
that
you
are
so
got
some
quick
notes
about
DNS.
Probably
you
already
know
that,
but
there's
a
trend
of
doing
TCP
for
DNS
more
aggressively,
so
that
may
be
related
to,
in
fact,
although
I
don't
think
a
DNS
over
UDP
we're
not
where
disappear
pretty
soon
and
the
secondly
there's
a
proposal
of
doing
the
application,
they
are
fragmentation
for
DNS
a
several
years
ago
and
I
think
it's
dead.
But
if
you
are
interested
in
it,
I'll
send
a
link
to
you.
Yes,
please
and
the
finally
different
right,
Ethernet
zero
doesn't
serve
this
program.
T
T
T
The
main
discussion
was
that
dns64
breaks,
DNS,
SEC
and
four
six
four
X
lat
can
be
used
without
the
need
of
using
DNS
64,
which
is
something
which
is
not
possible,
which
just
not
64
so
I
documented
that
and
presented
in
the
in
the
previous
meeting,
and
the
working
group
suggested
that
the
document
should
be
an
overall
discussion
of
deploying
nat64
and
not
just
for
64
X.
Let's,
so
that's
that's
what
we
have
right
now.
T
T
They
want
to
make
sure
that
everything
works.
So
I
look
at
the
perspective
of
the
different
scenarios
trying
to
see
if
everything
is
going
to
work
in
each
of
those
scenarios
and
the
scenarios
basically
look
into
considerations
about
how
it
works
depending
on
where
is
located
been
at
the
dns
and
if
there
is
or
not
a
silat
okay.
So
that's
that's
the
way.
I
have
look
at
the
scenarios.
I
I
don't
have
time
to
go
through
all
the
scenarios
right,
I
didn't
put
that
them
in
the
slides.
T
But
basically
the
idea
is:
you
can
have
an
operator
that
have
everything
in
their
own
network
or
maybe
the
case,
and
it
happens
already
where
people
is
using
an
external
DNS,
and
that
means
they
can
use
an
external
DNS
64,
and
this
is
something
I
blable
already
today
or
we
can
have
somebody
instead
of
using
their
own
nat64
having
a
third-party
operator
for
the
knot.
64,
okay,
so
those
are
the
different
possibilities
and
again
I
am
NOT
going
to
go
through,
but
I
think
at
the
end
is
something
like
six
basic
scenarios.
T
So
then
I
go
into
looking
into
possible
workarounds
for
the
main
problem,
which
is
breaking
the
DNS
SEC
and
the
workarounds
are
basically
either
not
using
dns64
and
then
I
look
into
each
of
the
scenarios.
If
that
is
going
to
work
or
not,
the
DNS
SEC
validator
is
aware
of
the
existence
of
that
dns64.
T
Then
I
look
also
into
the
possibilities
and
unperson
cons
of
using
a
silat
more
than
464
X
lat,
a
silat
or
a
network
with
silat
using
or
not
at
the
NS
64.
Then
I
look
into
something
which
is
very
common
today,
which
is
most
of
the
customers,
don't
use
the
DNS
provided
by
the
operator.
They
use
their
own
8.8.8.8.
T
So
is
that
going
to
work
and
what
are
the
consequences?
Each
of
the
scenarios?
Okay,
so
then
select
translation
considerations,
summary
of
deployment
considerations
and
also
I,
have
a
section
regarding
Ayana
consideration,
because
there
is
I
think
it
was
Mark
Andrews
who
submitted
an
an
amendment
and
also
recommend
their
soon
from
Ayane
for
the
IPV
I
think
it
was
six
only
dot,
ARPA
or
something
like
that
which
is
used
for
the
automatic
discovery
of
the
DNS.
T
Sorry
of
the
net
64
and
so
on,
and
in
the
case
that
errata
is
not
let's
say
moving
through
I
I
will
need
to
have
that
in
the
eye
and
a
consideration
section
right
and
I
think
that's
it
basically
I'm
not
sure
if
I
did
in
time.
Probably
I
have
something
like
five
minutes
for
each
presentation:
right,
yeah,.
T
Okay,
so
similar
situation
here,
I
presented
this
document
long
while
ago.
Actually
I
started
to
work
in
this
in
2006,
and
the
basic
idea
of
the
document
at
that
time
was
we
can
use
the
the
part
of
the
customer
prefix.
For
example,
if
the
customer
has
his
last
48,
we
can
use
the
first
this
last
64
for
the
point-to-point
link.
Actually,
when
I
did
these
lights
in
the
previous
presentation
in
Singapore
I
make
a
mistake
here.
I
said
that
31
percent
of
operators
were
using
that
I
took
the
the
wrong
number.
T
It's
actually
69%
of
operators
who
answered
my
survey
and
I
cut
already
more
than
1600
answers.
So
it's
a
big
representation
of
who
is
deploying
ipv6
worldwide
using
that,
and
there
was
also
a
document
from
dhcpv6
prefix
delegation
in
2012,
which
is
actually
supporting
the
way
to
do
to
do
this.
Okay,
so.
T
In
the
previous
meeting,
not
not
1:1,
it
was
100.
The
working
group
told
me
basically,
instead
of
working
in
only
this,
where
you
don't
brought
the
scope
of
the
document
to
look
into
all
the
possible
ways
to
to
deploy
the
point-to-point
links.
So
that's
what
I
did
summary
of
the
document
is
I
start.
T
Refreshing
about
61
64,
this
is
recommending
somehow
using
127,
but
it's
not
actually
saying
is
the
only
way.
It's
more
recommendation
for
router
vendors
to
make
sure
that
they
support
that.
Okay,
then
I
start
talking
about
the
different,
perfect
size,
size
choices,
so
I
review
what
it
says
in
RFC
776
zero
way,
which
is
basically
is
a
parameter
the
prefix
length.
T
So
we
could
perfectly
use
as
last
64
one
two
seven
one,
two
six
other
choices,
and
also
why
not
use
a
locators
last
64
and
just
use
one
two,
seven:
okay,
there
is
actually
a
document
that
we
developed
it
in
in
ripe,
which
is
Right
690.
A
thing
is
the
number
where
we
have
actually
look
at
into
some
of
these
issues,
not
all
of
them,
but
the
document
is
also
looking
in
issues
that
are
not
part
of
this
of
this
document.
T
I
look
also
into
prefix
traffic
spools
choices
like
we
can
just
use
like
we
typically
do
in
IP
before
a
different
pool
for
the
point-to-point
link
or
we
can
use
as
I
mention
in
the
first
slide
as
last
64
from
the
Nam
from
the
customer
preface
and
then
I
look
into
the
details.
Of
of
that
now
he's
stuck
Frette
can
do
yeah.
If
anyone
has
not
seen
the
disarray,
all
the
numbers
I
have
you
set
all
the
percentages.
I
have
used
it
in
in
in
in
the
document
and
in
the
slides
come
from
this
survey.
T
I
think
the
last.
The
last
person
of
my
survey
presentation
was
done
here
in
London
about
a
couple
of
months
ago
in
the
UK
enough.
So
you
can,
you
can
find
that
that
complete
set
of
slides,
but
these
are
the
figures
of
both
the
people
is
using
in
terms
of
one
perfect
size,
one
perfect
addressing
type
and
so
on.
T
T
Okay,
this
document
has
also
long
history.
The
first
thing
to
notice
is
that
it
should
be
somewhere
in
the
room.
I
have
now
a
1/4
I
asked
it
for
the
for
the
three
documents.
I
I
asked
it
if
somebody
wanted
to
contribute-
and
only
in
this
in
the
in
the
case
of
this
document,
I
got
a
yes
from
from
hands
from
from
the
link.
So
now
he's
also
part
of
the
document.
T
Basically,
in
that
document
we
had
the
broader
scope.
We
were
trying
to
update
error,
see
70
84,
which
hold
the
new
transition.
Mekinese
and
HomeNet
I
had
a
lot
of
versions,
and
then
there
was
a
pushback
from
the
working
group
and
then
in
Singapore
I
think
I
got
the
final
recommendation
for
from
the
working
group,
or
at
least
what
I
understood
looking
at
the
video
is:
keep
the
format
of
RFC
70
84,
but
use
the
document
as
an
extension
to
that
document.
So
take
online
consideration
supporting
ipv4
as
a
service.
T
A
T
So
the
point
is
is
clear:
we
don't
have
any
more
ipv4
addresses
people
that
the
ISPs
are
not
able
today
to
say
to
the
customers.
I
only
provide
you
ipv6
and
I.
Don't
support
your
people
for
devices
in
the
network.
There
is
no.
There
is
no
way
and
I
a
speakin
can
do
that.
Okay,
I,
like
it
very
much
the
presentation
that
we
have
about
hosted
services,
but
for
for
broadband
services
the
situation
is
totally
different,
so
we
cannot
go.
Unfortunately,
that
way.
T
So
so
the
the
basic
idea
of
the
document
is
working
over
that
the
CP
the
cities
need
to
support
ipv4
as
a
service.
We
will
get
in
the
next
few
years,
ipv6
only
access
net
course
in
some
cases,
for
example,
all
the
deployments
which
des
light.
This
is
the
way
we
are
doing
and
we
have
ipv6
only
one,
but
we
still
need
to
support
that
before
inside
of
the
customer
lands.
T
T
Basically,
the
the
document
is
looking
only
as
an
extension,
so
they
must
support
RFC,
1784
and,
in
addition,
using
the
same
style
as
RFC
1784.
If
you
want
to
support
these
transition,
mekinese
do
this
and
this,
if
you
support
this
transition,
mekinese
do
that
and
that
I
think
Barbara
actually
said
that
from
from
one
of
the
previous
documents,
that
was
the
scope
of
of
the
document-
and
we
just
did
did
the
same.
T
We
make
sure
that,
following
the
recommendations
of
the
previous
presentation,
we
have
a
problem
description.
We
have
a
scenarios
which
were
not
clear
in
ever
see:
70
84,
we
happen
user
architecture
which,
when
the
one
is
ipv6
only
but
ipv4,
is
still
needed,
and
we
also
explain
the
cost
of
code
to
support
these
new
functionalities
and
I.
Think
that's
basically
it
yeah.
That's
it.
F
I,
looked
at
not
six
for
document
and
I
got
totally
confused
because
I
read
it
as
don't
even
try.
It
might
be
just
me,
but
looking
at
your
scenarios
and
the
things
and
how
you
describe
what's
not
going
to
work,
you'll
scare,
people
away
and
I
do
not
think
it's
fair
approach,
because
we
do
not
know
a
number
of
scenarios
when
it
does
work
right
and
regarding
genus,
yep
problem.
F
F
No
no
I'm
knocking
about
actually
as
a
necessary
transport
also
needs
to
be
solved,
but
obviously,
oh,
my
god.
We
cannot
deploy
dns64
because
of
the
inner
circle.
We
cannot
deploy
DNS
SEC
because
of
na
dns64
I
think
should
be
just.
It
should
be
just
a
requirement
in,
in
addition
to
contributing
causes,
staff
for
creating
all
these
keys
in
your
zone,
you
also
need
to
add
quite
a
records
and
I
make
sure
we
six
deploy
tents
and
problem
solved.
I.
T
Totally
with
you,
I
think
and
I
believe
I
put
that
in
the
in
the
document.
I
think
there
is
Tex
speaking
about
that,
but
but
maybe
forgot
at
the
last
minute,
but
it
has
been
always
in
my
mind.
I
always
remember
that
you
did
the
testing
few
years
ago
and
I
think
it
was
one
point:
seven
failures,
because
the
lack
of
dns64.
F
That's
because
arrived
she
was
not
clear
and
there
are
different
implementations,
but
here,
if
it's
only
doing
synthesis
for
signs-
oh
yeah,
so
yeah,
if
it's
overlaid
between
signs
on
and
zombies
out
before
yeah
it's
about
one
percent,
so
it's
actually
much
much
less
than
DNS
a
problem
for
v6
transfers.
Actually,
who
cares?
Let's.
T
K
Starck
I
did
go
through
the
transition
technology
document,
I
think
it's
much
improved.
I
like
the
approach.
I
am
still
concerned
that
there
are
still
too
many
transition
technologies
and
I.
I
really
think
that
somehow
there
needs
to
be
a
determination
of
you
know,
number
of
operators
who
actually
want
some
of
the
various
technologies
and
maybe
somehow
try
to
weed
them
out
a
little
more.
K
H
Lee
Howard:
this
is
not
a
comments.
As
a
chair,
I
have
been
a
few
of
us,
it
was
I,
think
I
had
the
idea
and
several
people
contributed
to
a
listing
of
operators
who
are
running
various
transition
technologies.
Io,
a
pinochle
blog
post
on
this
and
I've
been
trying
to
actually
get
it
written,
but
but
yeah
I
will
I
will
send
some
send
that
list
to
to
the
basics.
Ops
lists
that
we
can
at
least
get
a
sense
for
who's
running
which
transition
mechanisms.
H
I
will
note
that,
to
my
knowledge,
no
no
major
operators
currently
currently
running
map
I,
think
that
is
not
because
of
a
failure
in
map
as
much
as
it's
a
newness
of
map,
both
T
and
E
I
think
are
of
interest.
I
do
have
one
large
operator
actually
charter
in
the
US
has
announced
they're
an
early
field
trial
for
map
T.
Let's
see
who
I
know
of
well.
T
But
in
addition,
in
addition
to
that,
it's
not
a
recommendation
to
say
you
must
support
this
and
this,
and
this
is
following
the
same
approaches:
RFC
72
for
would
say
if
you
want
to
run
this
duties.
If
you
want
to
run
that,
do
that,
so
it's
not
at
all
stating
you
must
support
all
four,
and
in
addition
to
that,
and
that's
what
we
have
the
code
consideration
section
all
the
data
plane
among
all
those
transition
mechanism
is
exactly
the
same
as
Diaz
like
which
is
already
in
RFC
seventy.
Eighty
four.