►
From YouTube: IETF104-6MAN-20190325-0900
Description
6MAN meeting session at IETF104
2019/03/25 0900
https://datatracker.ietf.org/meeting/104/proceedings/
B
B
C
D
D
So
we
have
two
sessions,
we
did
our
usual
thing
of
giving
priority
to
working
group
graphs
and
then
active
graphs,
and
so
we
did
this
generally.
The
working
group
graphs
getting
discussed
today
and
starting
to
do
active
drafts
on
Friday
morning
oops
and,
as
you
can
see,
so
we
have
a
lot
of
short
talks
in
the
end
of
Friday.
We
also
have
a
follow-on
session
for
the
segment
routing
discussion.
D
The
plan
is
that
the
authors
are
going
to
be
working
with
people
during
this
week
and
then
bring
hopefully
getting
the
document.
So
we
can
do
another
working
group
last
call
on
Friday
I
think
that
that
would
we
would
hope.
We
would
like
to
see
this
document
be
completed
and
move
forward,
and
we
also
received
a
number
of
the
general
requests
that
we
didn't
have
time
to
schedule
and
so
we're
listing
them
here
and
in
the
online
agenda.
E
Okay,
so
what
have
we
done
on
documents?
Since
the
last
idea?
We
got
to
published
RFC's,
that's
the
IP
six,
no
requirements
85
over
four
and
it
got
the
historical
original,
simple
IP
protocol
specification
published
as
well
as
RFC.
Eighty
507
I
encourage
everyone
to
read
that
one
to
see
what
the
initial
plan
was
for
this
project
call.
E
We
have
nothing
in
the
RFC
editor
cube.
We
have
two
documents
in
working
group.
Last
call
they've
been
there
for
a
while
the
segment
routing
documents
since
March
2018
is
that
what's
the
date
today,
also
by
the
end
of
this
week,
that
will
be
in
working
group
last
call
for
a
year,
that's
probably
a
record,
and
then
the
reader
advertisement
v6
only
flag
since
September
2018,
both
of
those
are
on
the
agenda
today.
Hopefully
we
can
close
these
documents
out
and
get
them
advance.
E
We
have
three
working
group
documents.
It's
the
ICMP
limits
document
spoke
to
Tom
and
he's
going
to
refresh
that
one
this
week,
I
believe
there
was
just
expired.
We
have
the
privacy
extensions
document,
the
base
document
for
that.
That's
on
the
agenda
to
talk
on
that
one,
and
then
we
have
the
prof
sixty-four
document
that
was
just
adopted.
That's
also
on
the
agenda
alright,
so
that
was
all
for
document
status.
Any
comments
on
that.
E
There's
one
ongoing
experiment
and
some
working
groups
using
github
for
documents,
and-
and
we
would
like
to
look
at
that
in
six-man
as
well
or
at
least
initiate
that
discussion
on
doing
that
here
in
six
man.
It
is
clearly
some
great
things
about
you
know
doing
a
a
source,
control
management
system
for
documents.
You
get
sort
of
the
same
benefits
that
you
do
for
source
code
right.
You
get
much
better
revision
control,
you
get.
You
know
at
least
we
think
you
might
get
much
more
focus
on
editing
the
documents
and
changes
in
their
documents.
E
E
Of
course,
some
of
the
downsides
would
be
that
you
know
perhaps
the
discussions,
wouldn't
you
know
be
on
the
open
on
a
mailing
list
anymore.
They
would
end
up
as
as
are
the
comments
on
pull
requests
on
github,
which
is
you
know,
we
don't
control
and
might
not
be
visible
for
for
everyone,
but
it's
in
write.
E
E
If
you
did
anyone
attend
yesterday's
session
on
github
tools,
there
was
one
tutorial
there
on
Sunday
there's
also
a
Thursday
working
group.
Is
it
a
working
group?
At
least
there
is
a
session
yeah
Andy
I
have
integration
and
tooling
there's
a
couple
of
drafts
here
worth
reading
as
well,
and
the
quick
working
group
I
think
has
done
taking
this
the
furthest
and
they
have
you
know
CI
tools
and
they
verify
the
XML
and
everything
sort
of
builds
automatically.
E
If
you,
if
you
push
and
you
draft-
and
you
could
sort
of
imagine
that
you
could
also
push
drafts
in
the
future
directly
to
the
IDF
or
submit
the
draft
to
the
idea
website,
if
you,
if
you
wanted
to
so
it
becomes
a
you
know,
a
new
tool
chain,
but
at
least
for
what
I've
seen
just
getting
a
different
way
of
dealing
with
document
edits
is
an
interesting
interesting.
Try
any
more
comments
on
doing
it
up.
G
E
D
D
So
we
added
a
host
configuration
option
that
controls
whether
the
host
should
process
this
flag,
and
the
notion
is
that,
if
it,
unless
this,
you
know
configure
it,
unless
it's
enabled
the
host
will
ignore,
even
if
it's
dual
sac
you
know
ignore
this,
the
notion
is
the
concern
raised
was
that
if
you're
in
an
ipv4
only
network,
there's
no
ipv6
services,
this
could
be
used
to
turn
off
IP
ipv4
maliciously.
So
this
gives
the
site
the
ability
to
have
it
set,
so
it
will
be
ignored.
D
We
also
in
this
line
we
changed
text
that
the
host
can
ignore
this
flag.
If
it
has
active
ipv4
configurations,
they
have
obtained
from
DHC,
and
so
it's
basically,
if,
if
you
have
working
v4,
then
don't
turn
off
before
it
seems
very
sensible
to
do
it
this
way
and
if
there's
no,
if
you
don't
have
any
active
communications,
then
then
you
should
listen
to
the
flag.
D
Some
text
clarification
to
improve.
You
know
what
the
administrators
intent
was.
We
had
Jorn
as
an
author
he's
made
a
lot
of
contributions
and
done
the
FreeBSD
implementation.
We
updated
the
information
on
the
contribute,
the
FreeBSD
implementation
and
there
are
a
number
of
editorial
changes
yeah.
So
so
at
this
point
we
have
freebsd
implementation.
D
So
so,
as
they
said,
I
think
the
the
main
issues
raised
were,
you
know,
will
be
used
by
a
bad
actor
to
turn
off
before
on
an
act
at
the
four-link,
and
so
we
think
that
the
host
configuration
is
one
way
of
protecting
and
that,
as
I
said
you,
you
don't
act
on
the
flag.
If
you
have
active
ipv4,
you
know,
if
you
just
have
v4,
that's
using
self
configured
addresses
and
there's
no
active
connections.
Then
you
should
be
listening
to
this
and
and
I
guess.
D
The
other
comment
is
that
the
rest
of
the
security
issues
are
really
the
same
as
you
have
with
all
other
control
protocols
that
run
on
on
the
link.
They
can
all
be
used
by
bad
actors
to
do
the
wrong
thing.
You
know
you
can
turn
off
before
you
can
break
before
with
the
four
just
as
well
as
with
this.
So
we
think
this
is
what's
in.
The
document
is
a
reasonable
compromise.
H
Yes,
I
think
the
document
is
really
nice
and
ready
for
publication.
I
have
one
comment,
a
question
because
I
just
realized
I
have
a
crazy
idea
of
using
Z's
on
dual
stack
network
so
because
currently
the
document
says
administrator
must
only
enable
it
on
v6
only
which
I
read
as
I
cannot
enable
it
on
dual
stack.
H
However,
there
is
a
use
case
for
this
on
dual
stack
when
I'm
trying
to
move
most
of
the
devices
which
are
capable
of
working
on
v6,
only
two
v6
only
mode
and
still
allow
legacy
devices
to
get
addresses
via
DHCP
before
so
I
kind
of
she's.
A
use
case
for
this
to
be
in
able
to
dual
stack.
So
do
you
think
we
can
relax
it
to
shoot
in
section
3.
I
D
D
D
D
Right
yet
yeah
and
that's
clearly
not
the
way
we
were
thinking
about
this,
but
I
think
think
about
it
more,
but
I
think
you
could
be
used
for
that
yeah.
So
conceivably,
we
could
add
some
text,
but
you
know
I
want
the
focus
to
remain.
You
know
it
is
an
ipv6
only
link
and
just
we
want
to
turn
off
the
background
before
traffic.
E
B
J
Let's
start
with
the
first
one.
In
the
current
version
of
the
document,
we
essentially
specify
two
alternative
algorithms
for
generating
temporary
addresses.
One
is
essentially
calling
several
random
number
generator.
Okay
and
the
other
one
is
essentially
modification
to
the
algorithm
in
72
seventeen.
K
That
excellent,
okay,
fine
yeah,
there
is
a
problem
with
having
a
concept
of
time
in
the
generation
of
addresses,
because
in
practice
you
want
your
advance
to
remain
stable
for
some
duration
and
that's
something
we
saw
in
MAC
address
randomization.
That
is
good
too
it's
stable,
so
that
there
are
two
notion
of
stability.
K
Is
that
if
you
come
back
to
some
network
that
you
visited
two
hours
ago,
it's
often
nice
to
keep
the
same
address
for
various
reasons
and
at
the
same
time,
if
you
come
back
on
the
same
network
in
a
week,
then
it's
not
nice
uh-huh.
So
so
you,
you
have
to
work
on
this
concept
of.
What's
the
stable
time
that
you
want
is
a
just
I
mean
a
Wi-Fi
session.
Is
that
a
day?
Is
that
mean
it
has
to
be
part
of
what
you?
What
you
are
trying
to
do
there
well.
J
In
one
of
the
next
few
slides
we
actually
well,
we
are
rising
that
you
know
question
too,
because
there
was
the
comment
regarding
of
adding
the
you
know
the
value
of
time
or
not.
For
example,
let's
say
that
we
are
just
using
you're
just
using
a
simple,
seldom
a
cell,
the
random
number
generator
without
a
you
know
the
any
time
parameter.
J
If
the
algorithm
is
that
you
know
whatever
you
want
to
generate
the
new
others,
you
just
select
a
new
random
number.
Then
the
question
is,
for
example,
what
happens
if
you
briefly
disconnect
your
link
and
then
you
reattach
again?
What
do
you
do
you
do
you
use
the
same
address
you
generate
a
different
one,
which
is
a
what
I'm
saying
is
that
it's
a
more
broader
issue
than
just
including
the
timer
I
mean
the
timer
makes
it
evident.
K
I'm
not
advocating
a
timer
I'm
I'm,
advocating
having
a
discussion
of
this
issue
and
balancing
different
solutions:
okay,
for
example,
this
one
potential
solution
to
say
that
we
don't
use
time
at
all.
We
assume
the
MAC
address
will
be
randomized
according
to
some
management,
I'll
go
with
them
and
then
we
use
that.
That's
one
possibility:
okay,.
J
But
I
think
that
you
know,
even
if
you
know
we
remove
the
the
time
parameter
from
you,
know
the
72
17
I.
Guess,
there's
still
the
question
whether
you
know
we
want
more
than
one
algorithm
in
the
document
have
more
than
one
and
recommend
one
of
them
have
multiple,
don't
recommend
any
just
keep
a
single
one
and
you
know
remove
the
rest
I'm
fine
with
either
option,
but
I
just
want
to
know.
What's
what
the
working
group
wants
to
do
about
this.
M
Yes,
Eric
line
I
think
I
have
a
slight
preference
for
at
least
keeping
a
reference
to.
Basically,
if
you
just
use
pure
randomness
to
journey
and
generate
one
each
time
as
a
possible
option,
also
I
think
the
issue
of
what
to
do
when
you
come
back
to
a
network
is
just
some
simple
text
about
whether
it's
up
to
the
operating
system,
whether
they
think
they're,
trying
to
resume
a
session
or
whether
trying
to
establish
a
new
attachment
to
it
to
a
network.
So.
J
M
So
the
it's
up
to
the
host,
if
it's
doing,
if
it's
doing
DNA,
for
example,
right
uh-huh
yeah.
So
if
it's
doing,
if
it
decides
I'm
doing
DNA
I've
been
in
this
I've,
been
in
there's
never
before
within
parameters
that
are
operating
system.
Specific,
it's
okay
to
just
attempt
to
reuse
the
address,
as
you
would
with
DNA
or
not
it's
up
to
the
operating
system.
Right
I
would
just
add
some
some
text
around
management
is
separate
from
address
generation
right,
agree.
M
M
M
N
J
N
Okay,
thanks
hi
Fernando,
Dave,
Wonka,
I,
guess
I
want
to
also
vote
or
my
preference
is
the
single
randomization
I'm.
Sorry,
can
you
hear
me
so
I
was
saying
I'm
also
in
favor
of
the
the
simpler
option
of
the
randomization.
A
one
thing
I
want
to
mention
and
I
think
you
know
this
and
I'm
not
sure
everyone
does,
but
in
in
mapper
G
in
the
last
couple
years
we
we
explored
the
possibility
of
we
noticed
with
privacy
addresses
that
you
can
count.
N
You
can
use
the
privacy
address
to
create
an
estimate
of
how
many
hosts
have
a
privacy
address
configured.
You
know
in
a
network
and
there's
some
really
nice
advantages
to
that
and
the
randomization
one
enables
that
the
thing
that
you
can
do
is
try
to
guarantee
anonymity
to
a
certain
size
anonymity
set
if
I
can
count
them
so
I
I'm
not
gonna,
go
into
the
details.
Now,
there's
a
we
have
a
draft
about
it
and
you
can
come
to
me
afterwards
about
it.
N
If
you
haven't
heard
of
this,
but
basically,
if
you
use
this,
the
straight-up
randomization
with
some
fairly
short
live
time
like
the
day.
That's
in
the
RFC
recommendation
now
we
can
produce
a
high
quality
estimate
of
how
many
hosts
are
there
and
do
an
it
hit
aides
anonymization
for
privacy,
so
that
particular
mode
of
operation
has
some
advantages.
N
J
The
thing
is
that
so
there
are
two
separate
questions.
One
is
whether
we
want
to
you
know:
remove
the
description
of
one
of
the
algorithms,
the
other
one
is
whether
we
want
to
recommend
a
particular
one.
So,
for
example,
if
I
understood
an
area
correctly,
he
wants
to
keep
off
and
leave
the
option
to
the
implementation.
Like
you
know,
pick
whatever
you
want.
Okay,
I
mean.
O
J
N
E
So
I
suppose
we
you
know
we
could
certainly
do
a
hum
for
each
of
these
options.
If
we
think
people
you
know
are
well
I
guess
we
could
ask
the
people
if
they
think
they're
ready
to
make
that
choice
or
if,
if
we
have
to
take
it
to
the
mailing
lists,
I
don't
know
any
views
on
that.
Are
people
ready
to
make
this
choice
now
or
do
we
want
to
take
that
to
the
main
list?
Well,
we
would
confirm
it
anyway,
but.
E
E
J
Yeah
all
the
questions
for
the
working
group.
We
had
in
a
different
ID,
a
set
of
requirements
for
the
temporary
addresses
so
far.
They
are
not
in
49:41
base.
So
there
was
the
question
whether
to
include
them
on
the
on
this
document
or
not,
essentially,
rather
than
specifying
I
mean.
This
is
like
something
similar
to
what
we
did
for
stable
addresses
on
one
hand,
we
had
the
algorithm,
but
on
the
other
hand
we
had
like
a
set
of
requirements
that
the
algorithm
should
fulfill.
J
Like
you
know,
the
addresses
shouldn't
should
not
be
predictable,
they
shouldn't
follow
patterns,
etc,
etc,
etc.
So
some
some
have
suggested
to
include
these
requirements
in
the
body
of
the
document.
Obviously
we
would
keep
the
algorithms
themselves.
Others
have
suggested
to
include
these
requirements
in
an
appendix
so
that
you
know
if,
for
some
reason,
people
wanted
to
use
a
different
algorithm
other
than
the
ones
that
we
are
describing
in
the
document
they
know
what
are
they?
You
know
the
the
properties
that
these
algorithms
should
follow.
J
J
Then
there
is
another
one
which
is.
This
is
a
change
with
respect
to
49
41,
which
is
the
current
version
of
the
document,
makes
temporary
addresses
on
by
default.
Now.
What
we
think
is
that
you
know
in
the
light
of
75
28,
you
know
that's
a
sensible
thing
to
do,
but
you
know
that's
a
change
that
is
already
in
the
document
from
49
41,
but
it's
up
for
the
working
group
to
to
discuss
whether
you
know
somebody's
against
that.
What.
E
J
J
I
get
this
goes.
This
could
go
as
a
question
to
the
mainland
list.
The
last
topic,
which
is
I,
mean
some
of
the
folks,
have
made
comments
about
this.
As
part
of
the
other
question
that
I
asked
is
whether
to
add
additional
references
regarding
you
know
when
systems
might
want
to
generate
the
new
address
or
not,
one
might
be
to
point
to.
You
know
DNA
for.
P
J
I
J
Recommendations,
if
you
want,
like
you,
know
one
of
the
things
that
one
of
the
issues
with
49:41
is
that
there
were,
for
example,
implementation
that
they
would
change
to
a
different
link
and
they
you'd
keep
the
same
interface
identifier.
So
they
might,
they
might
keep
the
same
interface
ID.
So
the
question
is,
or
the
thing
here
is
to
recommend,
at
least
like
you
know
you
to
generate
a
new
address.
At
least
you
know
when
these
things
happen.
J
I
J
I
J
A
sense
well,
this
is
kind
of
like
up
to
the
implementation,
I
guess-
and
there
are
like
a
number
of
things
that
you
know
will
bury
from
one
implementation
to
another
when
they
want
to
generate
like
a
new
one.
There
could
even
be
situations
in
which
you
know
some
operating
system.
I
want
to
generate
a
new
temporary
address.
For
you
know,
some
subset
of
applications,
for
example,
generate
the
new
temporary
addresses.
For
you
know,
web
browser
could
be
and.
I
I
guess
the
question
is:
are
you
just
trying
to
do
everything
to
maximize
Percy
of
the
user
and
then
push
the
impact
of
that
on
to
the
people
managing
the
network
or
people
like
Eric
who
are
trying
to
figure
out
whether
that's
a
session?
That's
we
continuing
or
genuinely
a
new
attachment.
I
guess
that's
the
question,
but
you
have
any
views
on
that.
Whether
we
should
try
and
capture
that
in
the
document
I.
J
Think
it
should.
My
personal
view
is
that
it
should
be
mostly
up
to
the
implementation
of
up
to
the
house.
Of
course,
there
is
a
it's
a
trade-off
right
on
one
hand
your
house
might
generate
my
one,
but
there's
we
have
the
BCP
about.
You
know
they
availability
of
addresses.
So
in
a
way
you
know
if
hosts
were
to
generate
multiple
addresses.
It's
within
that
PCP
I'm,
not
saying
that
it's
perfect,
but
it's
it's
a
recommendation
that
we
have
right
now.
Yeah.
I
I
mean
if
yeah,
if,
if
the
outcome
is
yeah,
the
host
can
generate
as
many
addresses
like
deal
with
it.
That's
that's
fine
I
just
think.
Maybe
we
can
put
some
wording
in
there
about
that.
Maybe
it's
not.
Maybe
you
think
we
shouldn't
just
leave
it
completely
neutral.
It's
that's
rewriting
it
it's
an
opportunity
or
updating
it.
It's
an
opportunity
to
move
that
trade-off,
slider
one
way
or
the
other
or
leave
it.
I
I.
J
Think
that
you
raise
an
interesting
point,
I
would
say
that
probably,
if
we
let's
say
try
to
impose
any
kind
of
like
constraints
on
that
which
you
know
my
benefit
the
network.
On
the
other
hand,
we
already
have
a
PCP
regarding
the
availability
of
addresses,
so
folks
would
say:
well
we
already
have
a
BCP
for
that
and
you
know
notes
are
free
to
generate.
You
know
how
many
others
is.
They
want.
Okay,.
I
Q
E
E
H
H
H
So
DHCP
is
not
an
option
here
by
definition,
PC
be
basically
the
same
right,
especially
if
the
host
uncontrolled
I
have
no
guarantees
that
supports
PCP
and
if
the
only
think
I
used
for
configuring
hosted,
slack
I
have
actually
no
desire
to
turn
on
additional
services,
especially
if
I
don't
know.
If
clients
are
going
to
support
it,
so
this
left
us
with
RFC
70/50
using
DNS,
to
discover
not
six
for
prefix
those
problem
use.
H
It
is
its
has
some
security
implications
because
you
kind
of
need
have
you
have
to
trust
it
in
a
sensor
which
can
be
easily
spoofed?
So
obviously
it
still
could
be
used
by
legacy
hosts.
But
what
we
trying
to
do
is
to
provide
host
in
with
not
six
for
prefix
in
more
secure
away
and
also
in
single
packet
host
could
get
all
configuration
information
instead
of
waiting
for
Dena's
exchanges
so
well.
R
R
I
will
try.
I
will
try
my
best
so
sorry
for
that.
Okay.
So
if
we
assume
that
the
information
which
is
in
slide
is
true
that
me
that
for
every
service
we
will
have
to
apply
and
to
give
us
arguments
as
as
an
argument
to
define
a
service
option
in
array.
So
it's
a
secure,
so
I
need
to
define
some
process
for
my
media
slide,
cgn
name
there.
So
I
have
to
be
able
to
define
an
array
option
because
of
this
argument
that
you
are
providing
here
these
slides.
R
So
thank
you
for
that
a
bit
way
and
then
I
need
to
define
for
us
a
sip
proxy
server.
Then
I
have
nothing.
I
am
only
Ryan
slack
only
Network
and
then
I
have
to
go
to
the
same
arguments
and
then
we
we
are
I
would
say
repeating
the
same
arguments
and
again
so
I,
don't
think
personally.
This
is
a
good
argument
to
justify
why
we
have
to
define
this
new
option
in
rice.
R
H
R
H
Me
answer
this:
slark
is
designed
to
provide
hosts
with
configuration
information
which
is
which
is
needed
for
basic
network
connectivity
right
I
am
not
aware
of
any
operators
who
think
that
all
the
hosts
need
to
be
provided
with
sip
proxy
to
get
basic
network
connectivity
while
dns64
in
and
not
six
flow
and
v6
only
network
is
basically
required
for
hosts
to
have
internet
connectivity.
So
it's
kind
of
special
case.
H
If,
in
future
we
see
any
other
use
cases
for
something
else
which
is
required
for
the
host
to
operate,
we
might
consider
I
believe
as
array
options,
but
I
think
we're
doing
it
on
case-by-case
basis.
I
haven't
used
case
when
my
hosts
need
to
be
provided
with
not
six
four
prefix.
Otherwise
they
couldn't
access
the
internet
reliably.
So
that's
why
I'm
such
a
suggestion
using
array
option
I,
don't
need
to
configure
SCIM
proxies.
R
As
an
operator
it
can,
but
the
other
operators
can
decide
that
the
you
want
to
have,
for
instance,
to
be
able
to
provide
some
specific
services
to
their
ipv6
a
host
using
using
slack,
and
you
can
not
one
date
to
the
other
operator,
how
you
can
do
it
just
because
for
you,
you
don't
think
this
is
a
basic
service.
I
think
this
is
where
it,
which
is
really
I,
would
say
and
agree
area
which
is
we
are
starting
either.
We
all
know
it
for
every
service
or
either.
We
are
really
careful
about
that
anyway.
R
Maybe
my
comment
is
not.
Is
it
really
about
this?
This
kind
of
legend
here
so
I
I,
really
don't
care
if
we
just
start
and
define
a
new
option
for
rail
and
for
not
64
and
so
on.
But
my
main
concern
is
that
there
is
already
there
an
ATF
consensus
document
which
we
have
went
all
all
of
this
all
these
options,
and
this
is
a
deserve.
You
solution
that
we
discussed
the
eruption
and
so
on.
R
H
May
I
ask
you
two
questions.
So
first
of
all,
I
know
suggestions
that
we
need
to
update
some
of
the
other
RFC's
resists,
because
I
assume
what
a
variety
of
decides
could
be
reconsidered
in
the
lights
of
new
operation
requirements.
So
that's
why
we
are
coming
to
this
solution
and
a
second
question
is
we
have
other
options
like
most
Pacific
routes
and
DNS,
and
so
what
shall
we
also
stop
using
them?
Because
we
will
have
other
ways
to
provide
the
host
visit
information,
yeah.
E
A
E
S
Okay,
like
I'm,
really
like
holding
my
mic
like
as
far
as
much
front
of
me
as
possible,
so
there's
something
in
the
room,
but
the
thing
I
want
to
say
is
whatever
phase
share,
so
the
router
should
send
stuff
in
our
ace
and
the
DNS
and
nat64
our
bono
cases.
So
me
dwelling
next.
What
is
next
like
a
sip
server,
but
that's
obviously
not
gonna
happen.
S
C
F
Okay,
we
get
the
good
average
I
guess
at
some
point
of
sign,
so
it
basically
says
view
that
if
the
configuration
information
is
fed
sharing
with
the
router,
it
needs
to
be
into
the
route
advertisement.
If
not,
it
can
be
in
the
HCP
and
then
dns64
and
96
for
a
border
case.
That
can
be
argue
whether
they're
our
basic
connectivity,
primitives
and
I.
Don't
think
this
will
extend
to
sip
server.
T
State
favor
speaking
of
the
mic
so
on
the
topic
of
70/50
I,
think
that
it
does
not
need
to
be
obsolete
or
whatever
I
think
they're
actually
for
different
use.
Cases.
I
think
the
use
case
that
you're
targeting
is
the
one
where
you're
configuring
the
router
and
you
want
security,
and
you
have
secure
Ras
deployed
right.
Okay,
I,
don't
know
how
many
people
actually
have
secure
Ras
deployed,
but
70
50
is
for
the
case
where
the
organization
that
deploys
the
net
six
foreign
dns64,
maybe
under
a
different
administrator
from
the
one.
T
H
Are
fair
enough
by
securing
our
a
I'm
not
necessary,
mean
send
I
mean
I
can
guarantee
that
my
host
receiving
arrays
only
from
my
router
to
some
degree
right
so
I
can
prevent
rogue
host
to
send
array.
So
I
can
say
yeah
my
arrays
are
reasonably
secure
and
if
I
have
someone
sending
malicious
re,
I
have
bigger
problems
and
not
six.
For
if.
T
H
T
M
Erik
line
yeah
yeah
in
the
sense
the
RA
option
allows
each
and
to
not
have
to
have
dns64
at
all.
That's
the
point.
So
if
you
have
lots
and
lots
of
DNS
over
TLS
or
DNS
or
HTTP
or
some
other
things,
and
you
can
actually
have
the
host
do
DNS
these
for
synthesis
on
device
and
not
have
to
have
not
have
to
talk
to
a
dns64.
H
C
H
H
Yeah
another
concern
raised
was
that
it
should
be
configured
on
the
router,
which
is
a
creational
nightmare
and
I
kind
of
disagree,
because
we
already
have
to
configure
prefixes
for
slack
DNS
services
preferred
lifetimes
and
other
things,
and
normally
automation
take
care
of
this.
So
it's
not
a
bug,
it's
a
feature,
so
we
can
allow
all
those
information
to
share
fate
with
routers,
because
it's
directly
related
to
origin
queries.
It's
not
six
for
prefixes
going
so
obvious.
I
do
believe
it
makes
sense
to
share
afraid.
H
I
was
around
information,
so
it
was
some
concerns
raised
about.
Let's
unify
dhcpv6
and
our
options,
to
be
honest,
I
did
not
really
get
it
and
anyway,
I
believe
it's
kind
of
out
of
scope
of
this
draft
and
if
you
start
doing
this,
we
can
have
another
conversation
about
this.
But,
to
be
honest,
I
just
like
to
let
my
hosts
in
v6
only
network
to
get
prefix
and
see
implementation
as
soon
as
possible.
So
we
received
a
number
of
suggestions
for
the
document.
H
I
first
mark
I
didn't
exclude
set
for
the
four
ranges,
honestly
I
kind
of
think
we
should
be
doing
this,
but
probably
not
in
this
option,
because
again,
this
option
is
mostly
useful
on
v6.
Only
network
exclude
set
would
not
be
really
useful
on
v6
unless
scenario
it
would
be
used
as
well
in
dual
stack
with
DNS,
not
six
for
network.
So
probably
we
just
can't
have
another
array.
Option
and
I'm
kind
of
volunteering
can
write
a
draft
if
you
think
it
should
be.
H
We
need
this
option
so
nan
/,
96,
perfect
support,
we've
heard
about
one
use
case-
have
not
heard
about
others.
So
first
question:
shall
we
be
doing
this
and
if,
yes,
how
because
the
current
proposed
option
format
is
trying
to
kind
of
minimize
the
size
of
the
option,
so
we're
not
inflating
inflating
array
too
much.
So
we
came
up
with
two
ideas
of
how
you
can
support.
H
Nan
/
96
prefixes
first
of
all,
obviously
is
just
add
prefix
length
in
the
top,
which
unfortunately
means
you
significantly
increase
the
size
of
sorry
always
so,
even
if
you
use
slash
96,
which
I
suspect
will
be
the
most
common
use
case,
you
still
have
a
large
array
option.
Another
slightly
more
crazy
approach
is
to
have
graphically
prefix
length
and
the
end,
and
if
the
option
lengths
is
2,
then
you
know
that
it
/
96
and
if
option
lenses,
threes
and
you
get
the
perfect
length
and
the
bottom
of
the
option.
H
The
benefit
of
this
is
that
you
basically
do
not
need
to
have
large
option.
If
you
use
slash
96,
so
you
can
save
some
space
and
I
think
we
have
presidents
with
route
information
option,
which
is
also
variable
length.
So
it's
not
something
so
uncommon,
I,
actually
don't
have
any
preference.
So
I
would
like
to
us.
The
shipper
can
grow
opinion
on
this,
and
another
option
is
yeah.
H
H
It
was
some
confusion,
apparently
in
the
text
about
why
we
saying
that
we
using
only
one
option,
one
prefix
for
all
destinations
and
at
the
same
time
the
option
might
appear
more
than
once
in
the
array.
So
we
clarified
the
text
a
bit.
Hopefully
it's
more
readable
now
and
so
now.
I
would
like
to
hear
some
suggestions,
options.
U
Mark
Andrews
the
excluded
addresses.
If
we
go
down
the
variable
array,
length
path,
adding
exclusion
of
adding
the
exclusion
information,
it
could
be
optional
and
I
could
we
could
do
is
exactly
the
same
thing
as
you're
doing
with
lengths
you
have
a
prefix
length
and
then,
after
that
you
have
a
DNS
address
where
you,
where
you
pick
up
the
information
from
for
the
exclusion
information
you
don't
have
to
include
including
code
exclusion.
Information
in
that
were
in
that
in
the
option
itself,
you
just
need
to
have
a
pointer
to
where
you
can
find
it
well.
H
U
Basically
you'd
have
prefix
length
and
then
a
DNS
address,
included
and
encoded
in
the
DNS
for
encoding
with
the
route
saying
there
is
no
address.
There
is
no
information,
so
you
get
prefix
length
and
one
more
bite
if
you've
got
no
information
or
if
there's
no
information
and
no
prefix
length,
you
do
the
short,
alright
yeah.
H
Q
I
would
like
to
ask
one
thing:
is
the
option
able
to
transfer
through,
for
example,
CPE
because
I
do
have
a
similar
draft
which
solves
the
issue
differently
and
I
have
been
getting
this
question
if
the
option
is
able
to
transfer
through,
for
example,
rotor,
because
if
you
do
have
a
provider
which
support
which
gives
you
this
option
of
the
prefix
as
first
Explorer?
Not
if
such
device
after
the
CPE
would
also
receive
it.
H
E
W
There
we
go.
How
is
that?
Okay,
alright,
so
the
SR
header
revision,
17
was
attempted
to
publish
and
it's
just
finally
published
now-
you
guys
can
see
if
there's
been
some
updates
done
to
it,
so
we're
gonna
cover
what's
in
revision.
17
in
in
this
talk
once
again,
thanks
to
all
the
collaborators
and
partnerships,
we've
had
the
the
vendors,
the
service
riders,
the
members
of
this
working
group
for
commenting
and
contributing
to
this
draft.
W
W
There's
been
24
revisions
of
the
drafts.
There's
been
a
thousand
emails
approximately
on
six-man
mailing
lists
from
a
basic
search
like
that's
one,
email
per
line
of
text
or
very
close
to
it.
There's
been
a
large
number
of
ITF
presentations
and
35
versions
of
the
draft
have
been
submitted,
since
it
was
a
individual
submission.
W
There
are
a
lot
of
implementations,
so
I'll
go
through
them
relatively
quickly.
These
ones
I
think
everyone's
well
aware
of
I've
talked
about
them
before
and
2017,
and
then
ongoing
updates
to
Linux
as
a
410
Linux
SR
extensions
and
FDI
o
VPP
with
SR
v6
support
in
all
three
of
these,
including
what's
in
the
SR
header
and
beyond
cisco,
has
shipping
code
with
the
SR
header
on
the
ASR
9000
5500,
a
bunch
of
iOS
XR
platforms,
and
that
is
shipping
today
and
shipping.
W
W
We
have
an
eye
chart
of
research,
publications
on
SR
v6,
everything
from
some
very
cool
load,
balancers
to
some
Sdn
architecture
for
for
networks.
Some
enterprise
use
cases
basically
lots
of
stuff
there
you
can.
You
can
take
a
look
at
the
presentation,
offline
and
and
browse
these
as
much
as
you
want.
W
There
have
been
interrupt,
bind
2017
for
l3
VPN
with
traffic
engineering
and
service
programming
between
FDI
OH
barefoot,
Tofino
implementation,
Cisco's
NCS
5500,
which
is
using
commercially
available
NTU,
so
other
platforms,
other
than
just
Cisco's,
can
be
building
s
r,
v6
solutions
based
on
that
and
the
ASR
1000
family,
using
a
custom
Cisco
ASIC
again
at
an
Tech
2018,
there
was
LT
l3
VPN
with
traffic
engineering
and
TI
LFA.
That
was
interrupted
between
the
NCS
5500
and
Strada
comics,
the
Inspiron.
W
Release
wise
and
deployment
wise
softbank's
of
course,
announced
their
nationwide
SR
v6
core
network,
utilizing
the
content
of
the
SR
header
draft,
a
bunch
of
services
that
are
in
that
work
programming
beyond
what
we're
working
on
here:
extensions,
nice,
a.s
and
BGP,
along
with
ping
and
traceroute
support
from
the
OEM
draft.
That's
going
to
be
presented.
W
So
that's
the
end
of
implementations,
all
right,
I
suppose,
if
we're
for
going
on
on,
what's
been
developed,
what's
been
deployed,
what's
been
released,
there's
a
lot
of
investment
on
this
draft
from
vendors
from
service
providers
and
it's
been
I
think
fairly
well
well
deployed
so
far,
even
though
it's
still
perhaps
early
in
its
life.
So,
let's
take
a
look
at
changes
in
16
and
17,
and
the
deployment
model
in
revision
16
was
updated
really
to
concentrate
on
how
we
secure
the
SR
domains
from
external
attempts
to
use
it's.
It's.
W
So
it's
pretty
well
described
now
in
the
deployment
model
as
a
revision,
16
revision,
17
we've
removed
the
reference
to
network
programming
that
was
asked
for
by
some
one
of
the
open
issues
or
actually
two
of
the
open
issues
were
on
that
TLV
processing
limits
were
added.
This
was
again
to
start
to
address
another
TLV
related
issue
that
that
we
have
in
the
issue
tracker.
There
may
be
more
work
to
do
there,
but
we'll
see
this
week,
we'll
see
from
comments
that
people
have
we've
had
some
updates
to
pad
TLV.
W
Some
minor
descriptions
made
sure
a
discovery
covering
the
destination
address
of
the
packet
and
it
matches
the
first
segment.
W
The
extension
header
processing
rules
were
updated
to
make
it
clear
that
extension
headers
are
in
fact
processed
in
order
and
we're
not
skipping
any
of
them.
That
wasn't
apparently
wasn't
clear
in
the
previous
revision
I
think
there
was
some
confusion
on
that
and
flow
labels
are
required
in
this
draft
for
intra
SR
domain
communication
as
well.
So
previously
we
had
flow
labels
required
for
inter
domain.
W
This
draft
adds
some
for
intradomain
there's
a
section
that,
like
Adrian
somewhere
here,
it
pointed
out
a
while
ago
that
we
needed,
which
was
more
description
around
what
a
designated
expert
is
supposed
to
do
when
assigning
making
assignments
out
of
the
Ayana
portions
of
this
draft
are
specified
the
flags
and
TLV.
The
description
in
that
section
now
follows
the
best
practices
in
8126
so
requires
a
working
group
draft
and
requires
notification,
this
six-man
and
describes
what
what
sort
of
time
frame
is
required
and
how
the
expert
reviewer
should
respond.
W
W
However,
on
the
tag,
processing
I'd
sent
an
email
look
to
the
list
this
past
week
on
this
tag,
processing
as
it's
defined
in
the
draft
is
well.
The
processing
is
defined
at
least
saying
that
a
was
how
a
source
end
point.
No,
it
should
be
handling
it
when
we
don't
have
a
use
case
defined.
We
don't
have
a
use
case
to
find
in
the
draft
and
looking
at
how
to
actually
document
in
this
draft.
W
What
those
use
cases
might
be
and
and
and
how
the
tag
field
might
be
used,
was
going
to
be
a
fairly
large
amount
of
information
to
put
in
here.
We
think
that
it's
still
better
to
leave
that
to
a
separate
draft
to
define
various
various
use
cases
and
and
and
and
how
that
tag
would
be
used
to
identify
a
group
of
packets
at
the
source
for
processing
at
some
segment.
W
End
point:
on
the
TLV
side:
the
let's
see
the
the
tlvs
are
really
that
fundamental
part
of
the
SR
architecture,
where
we
want
to
get
that
integrated,
underlay
and
overlay
and
service
chaining
solution
implemented,
and
we
need
to
be
carrying
metadata
along
with
with
some
of
those
segments.
The
TLB
provide
a
space
for
that
metadata,
and
it's
important
that
we
include
that
space
within
the
SR
header.
W
On
the
management
section,
this
was
something
back
at
ITF,
103
I
noted
that
we
want
to
take
a
look
at
I.
Think
at
the
point
where
we're
at
now.
We
don't
have
a
management
section
defined
in
this
draft
yet,
and
we
don't
have
any
example
text
on
what
that
might
be.
It's
probably
a
good
idea
at
this
point
to
leave
that
for
another
document
to
describe
any
additional
management
requirements
around
us,
every
six
and
oh
there's
various
gaming
models
that
are
coming
out
for
SR
policies.
W
W
P
X
W
Y
To
the
TLV,
there's
actually
two
questions
I
think
so
one
is
why
are
TLV
is
required
in
the
segment
routing
header,
as
opposed
to
using
say
a
destination
options
before
the
second
outing
header?
The
other
question
is,
if
you
do
have
tlvs
in
the
segment
rounding
header,
why
would
the
definition
and
the
up
and
the
requirements
be
different
than
hop
I,
hop
options
or
destination
options?
Y
So,
for
instance,
one
of
the
big
differences
is
that
there's
a
modifiable
bit,
however,
in
the
segment
routing
tlvs,
the
type
and
the
length
are
not
covered
in
a
modifiable
bit
by
the
off
header.
There's
your
doubt,
that's
very
different
from
RFC
8200,
so
I
think
the
implication
there
is-
and
this
is
probably
something
that
has
to
be
closed.
Y
I
think
at
one
point
there
was
the
idea
that
segment,
routing
tlvs
could
be
inserted
or
deleted,
and
it's
unclear
from
the
current
discussion
is
that
something
that
is
intended
or
if
it's
eliminated,
if
we're
never
going
to
do
that,
then
I
don't
see
any
reason
why
the
segment
routing
TLV
should
be
any
different
than
hop-by-hop
or
destination
options.
Yeah,
okay,
so
I
see.
W
W
So
so
that's
that
that's
the
two
of
them.
Alright,
that's
the
first
one,
the
the
second
one,
that's
the
technical
reason,
the
they
I
think
more.
The
design
reason
is
that
is
it
about
when
you're,
when
you're,
defining
a
segment
list
and
you're
defining
a
I
guess
the
source
routing
as
a
solution,
keeping
the
segment's
and
the
and
the
options
associated.
W
Z
Halpern
with
Erickson
the
question
on
your
most
recent
comment:
I,
don't
see
where
the
current
document
draws
a
distinction
in
kinds
of
segments.
Much
less
says
this
kind
of
segment
must
look
at
tlvs
and
this
kind
of
segment
must
ignore.
Tlv
is
you
may
have
implemented
it
knowing
what
was
safe?
But
that's,
not
an
interoperable
implementation.
Saying
there
was
a
shortcut
you
could
take,
doesn't
help
us
so.
Z
Rules
for
tlvs
have
to
be
defined
here.
They
can't
be
added
later
you're,
justifying
putting
the
tlvs
here
technically
on
the
basis
of
processing
rules
which
are
not
here.
I
can't
see
how
that
can
be
a
justification
for
including
the
tlvs.
Technically,
it's
not
here,
you're,
not
spelling
it
out.
How
can
it
be
a
behavior
that
drives
the
redesign?
Ok.
W
Z
Z
O
Fun
others
do
consider
the
acceleration
only
user
praying
specification
so
that
it
will
be
defined
in
Deseret.
It's
very
useful
because
the
the
entity
of
the
the
user
praying
of
warding
desire
defined
in
the
other
sto,
because
a
CBP
consider
a
study
to
to
to
put
the
year
some
parameter
in
the
other
metadata
in
the
servitor.
C
O
The
city,
our
principle,
to
to
study
the
the
other
candidate
of
the
user
plan,
but
also
yeah,
the
processing
theory,
is,
could
be
defined
in
the
entity
of
the
dot
user
pram,
so
to
confine
the
all
of
the
metadata
assert
its
the
absolutely.
How
about
you?
Thank
you.
Okay,.
F
AA
Chumlee
from
Hawaii
and
I
have
two
comments,
and
the
first
one
there's
TLB
until
the
stranger
option.
Header
has
the
same
functionality
which
the
TV
in
SH,
but
actually
for
me,
I
think
that
if
we
put
the
cherries
inside
the
SI
h,
which
is
it
means
the
segment
list
would
be
better
for
how
we're
processing
right
and
the
second
one
is.
Actually
we
have
several
implementation
already
and
our
customers
require
as
obvious
except
estava
sex,
and
we
hope
those
authors
to
address
the
issues
as
soon
as
possible,
because
it's
a
long
tongue
yep.
AB
Z
AB
The
for
the
forelli
so
coming
back
to
kill
me
I,
have
a
draft
which
is
agenda
hopefully
today,
but
just
to
add
what
Aaron
said
when
to
process.
Tlv
is
a
property
of
the
state.
If
this
is
the
notion
of
programmability
of
the
network,
so
let's
say,
for
instance,
see
in
van
onm
use
case.
That
is
there
in
the
draft.
It
allows
more
flexible
implementation
that
all
nodes
along
the
path
doesn't
have
to
look
for
the
TLV
based
on
the
local
said.
AB
The
node
knows
whether
look
for
TLV
or
not,
which
is
which
is
the
true
notion
of
programmability.
So
it
goes
back.
So
if,
if
we
go
with
destination
option
or
hopper,
how
option
you
lose
the
entire
basis
of
a
services,
the
programmability
as
second
efficiency
aspect,
so
in
addition
to
the
hardware
efficiency,
there
are
Network
wide
efficiency
and
there
are
many
use
cases
and
and
in
when
onm
is
one
of
them
where
we
can
take
advantage
of
it,
because
not
all
nodes
in
the
network
is
capable
of
processing
TLV.
Y
So,
on
the
subject
of
local
policy,
this
is
used
several
times
in
the
draft
and
in
some
cases
it's
very
open-ended,
like
it's
up
to
local
policy,
how
to
process
tlvs
in
certain
cases,
and
the
thing
is:
that's
so
broad
that
it's
almost
like
an
implementation
could
decide
to
process
these
things.
However,
they
want
it's
an
unlimited
open-ended
thing,
which
makes
me
wonder
how
you
derive
interoperability
and
conformance
from
that.
So
I
think
in
the
draft
I
personally
would
prefer
to
configuration
as
opposed
to
local
policy,
where
you
have
maybe
two
choices.
Y
You
can
configure
it
this
way
or
this
way,
but
the
open-ended
local
policy
and
the
comment
that
we're
building
this
on
the
assumption
that
there's
going
to
be
things
later,
that
that
further
define
or
clarify
that
I
think
you
know
going
back
to
the
previous
points
we
have
to
have
in
in
the
draft.
It
has
to,
in
a
sense,
be
complete
such
that
I
can
implement
this
without
having
to
make
assumptions
or
guesses
about
what
the
right
local
policy
is.
Yeah.
W
So
I'd
say
we're
at
this
point:
we're
not
making
guesses,
there's
that
there's
a
number
of
drafts
already
that
are
defining
tlvs
and
and
how
or
when
they
get
processed.
So
so
that's
that's.
You
know,
that's
beginning
to
happen,
and
the
involvement
of
of
this
working
group
in
the
spring
working
group
in
those
drafts
will
will
shape
all.
Y
AC
Roby
inferno,
javi,
I,
think
I
know
that's
their
the.
What
is
caution
regarding
that
here
is
in
the
Asajj.
In
fact
that
we
already
proposed
these
some
user
cases,
you
know
either
dropped.
That's
the
SRA
PR
we
use
the
useful
for
such
a
u-lock
uses.
So
I
am
a
suggestion
you
that,
because
of
these
use,
cases
depend
on
the
SR
actual
draft
and
instead
the
SRO
draft
that
depend
on
these.
The
possible
use
cases
of
the
theory
is
the
draft.
AC
So
my
suggestion,
since
this
is
the
usual
case,
is
the
justified
the
theory
usage
in
the
SRH
header.
So
my
suggestion
you
that
the
this
draft
user
just
use
the
prop
hold,
is
the
definition
of
the
theory
in
the
SRH,
but
for
the
problem
is
offered
our
way
for
such
that
the
user
cases
should
be
in
tuh
or
the
hubbub
I
hope,
I
hope
how
their
or
the
SRA
should
carry.
I.
Think
that
can
be
addressed
that
you,
the
user
keys
offered,
is
that
you
are
we
used
to
craft?
That's
my
commerce,
okay,.
AD
Hi
Darren
Ron,
Bonica
juniper,
this
discussion
about
tlvs
and
destination
options
could
go
on
for
a
very
long
time
and
the
reason
why
is
we're
making
design
decisions
based
on
poorly
understood
requirements
right
now
we
know
about
exactly
one
TL
v,
the
H
Mac
and
we're
not
quite
sure
we
understand
that
completely
may
be.
A
good
thing
to
do
would
be
to
leave
the
door
open
to
doing
it
either
way
later,
when
we
understand
more
tlvs
and
more
requirements,
leave
the
door
open
for
now
move
them
out
of
the
document.
AD
W
AD
AB
This
is
like
everything
is
spelled
out
in
this
draft
and
there
are
so
many
use
cases
drafts
that
are
there
then
claiming
that
we
don't
know
what
is
the
usage
when
their
application,
their
implementation
that
exists
for
using
those
tlvs
makes
no
sense
to
me,
and
and
and
and
with
all
due
respect,
Ron
I
mean
there's
a
point
where
we
have
to
differentiate
between
political
interests
and
the
actual
reality
of
the
world.
I
mean
this
is
this.
AB
Is
this
work
has
been
going
on
for
six
years
and
and
and
this
discussion
had
been
going
on
for
more
than
a
year
about
this
tlvs
and
and
and
and
you
seems
to
be
stuck
with
this
and
he
seems
to
be
always
cleaning
remove,
remove,
remove
chop
chop
chop
where
everything
is
properly
defined,
I
mean
I.
I
think
you
have
to
be
reasonable.
I
was.
AB
AB
AD
W
Okay,
so
if
you
were
to
use
the
same
logic,
then
destination
options
would
have
never
been
published
in
2460,
because
they're
exactly
two
TLV
their
pad
and
and
pad
one
rightly
there
was
no
TLV
there
fine
defined
either.
So
we
define
these
things
so
that
we
can
we
can
build
on
them.
We
can
build
product
on
them.
That
is
this
useful
to
the
network
and
it's
useful
to
it's
useful
in
deployments
and-
and
you
know,
let's,
we
define
the
vape
the
base
and
we
we
allow
the
innovation
to
happen.
AD
W
Don't
know
all
the
use
cases
before
you
start,
you
know
some
of
them.
You've
got
a
you've,
got
a
good
view
as
to
where
things
are
going
and
you
make
the
best
engineering
decision
you
can.
With
the
information
that
you
have.
You
know
you,
you
take
one
step
forward
and
you
keep
taking
another
step
forward
and
another
step
forward
until
you
get
close
to
that
right
solution
and
that's
where
we
are
we're
taking
one
step
forward.
AC
Yo
javi,
okay,
I
already
mentioned
I-
think
the
issue,
not
as
a
task
officer
drafter
to
defend
all
the
possible
theories
of
SRH
I.
Think
that's
the
user
I
already
mentioned.
This
is
the
design
of
this.
The
purpose
of
that
er
we
are
saying
Edessa.
The
first
is
the
integral
in
tikrit
head
of
the
solution
for
the
SRH,
so
there's
the
the
segment,
and
also
this
is
the
segmental
East,
and
that
here
we
can
be
incorporated
here
in
the
one
part.
This
is
the
first
one
I
said
in
the
one:
less
you
the.
AC
They
are
already
that
you
Decatur
to
draft
a
proposal
to
justify
that
you
are
we
that
can
be
used
in
the
SRH,
maybe
not
a
user
th
or
the
hop-by-hop.
This
is
the
opener
header,
so
the
one
I
think
that's
the
I
think
the
purpose
of
the
SRH
is
adjusted.
Who
proposed
this
the
more
capability
of
the
network,
a
program
I
mean
I,
think
based
on
this
one
I
think
we
proposed
this.
AC
AB
E
E
Personally.
I
don't
quite
see
the
difference,
but
between
in
all
of
these
are
containers
right
that
carry
tlvs
that
are
not
yet
defined,
like
the
Hopis
up
options
or
the
destination
options.
I'm
not
quite
sure,
I
see
sort
of
the
significant
difference
between
this
option
and
the
other
ones
we
have
and
if
I
recall
correctly
and
I'm
not
sure
I
do
but
I
think
we
did
discussion,
we
had
unlimited
domains.
The
working
group
did
ask
you
to
add
the
H
Mac.
E
As
you
know,
an
answer
to
the
security
concerns
of
crossing
limited
domain,
so
I'm
uncomfortable
of
you
know,
suggestions
or
going
back
on
that.
But
if
there
are
in
clear
interoperability
issues
with
the
Till's,
we
tell
these
that
are
there.
You
know,
please
propose
text
and,
and
clarifications
are
famed
and
clearly
you
know
TVs
that
don't
exist.
We
can't
specify
but
I
think
that's
fine.
E
E
The
week
yes,
so
we
have
asked
the
author's
you
know
with
a
strong
encouragement
to
work
through
all
these
issues.
During
this
week
we
have
a
Friday
session
to
summarize
this,
and
you
know
please
any
issues
you
have,
let's
work
through
them
this
week.
We
have
ample
time
between
Monday
and
you
know
today
and
Friday
so
yeah.
E
W
Y
J
Oops,
okay,
so
this
is
for
another
gun,
presenting
document
we
go
out
or
with
a
young
horse.
The
title
of
the
document
is
slacks
reaction.
To
remembering
events,
there
are
a
number
of
scenarios
that
you
know
can
lead
to
the
problem
that
we
are
discussing
in
our
ID
we're
going
to
focus
just
on
one
specific
of
those
scenarios.
J
So
here
we
have
a
typical
ipv6
deployment
scenario
in
which
you
have
a
CPA
router
that
does
DHCP
prefix
delegation
with
the
ISP
and
it
advertises
a
sub
prefix.
We
are
slack
on
the
local
network,
okay,
so
the
question
is,
for
example,
what
happens
when
these
cpu
router
crashes
and
reboots,
for
example?
J
J
Obviously,
the
outcome
of
this
is
that,
since
the
no
previously
configured
addresses
have
become
invalid
or
stale,
any
communication
employing
those
addresses
will
fail.
Obviously,
depending
on
the
scenario,
if
it's
a
six
only
scenario,
communication
might
completely
fail
if
there
is
before
connectivity
and
the
application
employees
happy
eyeballs.
That
might
mean
that
you
know
the
resultant
traffic
is
ipv4,
etc.
J
There's
the
right
document,
I,
don't
remember
the
690
okay
then
write
690
document
about
the
discusses,
the
you
know,
the
the
assignment
of
prefixes,
and
they
actually
describe
a
little
bit
this
problem
and
what
they
do
in
that
document
is
recommend
that
ISPs
lease
stable
prefixes,
what
persistent,
okay,
persistent,
stable
prefixes.
The
idea
is
obviously
that
you
know
if
you
always
list
the
same
prefix
to
the
CPE
router,
even
if
the
CPU
rotor
crashes
and
reboots,
it
gets
the
same
prefix.
So
nothing
changes
there.
J
There
are
a
number
of
reasons
for
which
that
might
not
be
the
case,
but
some
of
them
you
might
agree
or
not,
but
I
would
say
that
at
the
end
of
the
day,
the
thing
is
that
you
have
deployments
that
employ
dynamic
prefixes
for
different
reasons.
Among
others,
there
are
ISPs
that
simply
want
to
cherish
more
for
stable
prefixes
against
DC,
says
deployment
reality.
Then
you
might
say
well,
this
is
right.
I,
you
do
things
differently.
This
is
what
we
have
there's
another
thing
that
could
be
done.
J
You
know
to
avoid
this
problem,
to
some
extent
is
to
have
the
CPU
routers
record
the
prefixes
that
have
been
leased
on
stable
storage.
So
the
idea
is
that
when
the
CPE
router
crashes
and
reboots,
it
remembers-
where
was
the
prefix
that
had
been
leased
before,
and
the
CP
robber
could
somehow
try
to
invalidate
the
prefix?
That
can
be
tricky
for
a
number
of
reasons.
J
J
Another
thing
related
with
this
is
that
there
are
implementations
that
enforce
limits
on
the
number
of
addresses
that
they
will
configure.
So
since
the
CPS
cannot
completely
remove
the
addresses
configured
for
these
prefixes.
Well,
you
might
by
unprofor
the
addresses,
but
you
will
keep
the
old
addresses.
So
if
the
reboots
are
frequent,
then
you
might
end
up
hitting
the
system
specific
limits,
for
you
know
the
maximum
number
of
addresses
that
can
be
configured
so
how
we
think
this
should
be
solved.
J
The
the
main
mitigation
for
this
problem
that
we
proposed
in
the
document
is
to
try
to
infer
that,
when
you
receive
erase
from
the
same
router
that
you
were
receiving
erase
before
these
arrays
include
prefix
information
options
for
other
prefixes
and
not
for
the
yeah
for
the
previous
one.
Then
you
infer
that
these
prefixes
have
become
stale.
Since
we
publish
the
talk,
this
recommend
there
was
a
lot
of
discussion.
J
Actually,
if
you
follow
the
6-month
discussion,
it
was
over
like
300
messages,
and
while
we
were
discussing
this
topic
yesterday
doing
and
after
the
IEP
team
meeting,
there
were
suggestions,
for
example,
not
to
let's
say
completely,
act
in
response
of
these
arrays
again
arrays
from
the
same
router.
They
include
prefix
information
options,
but
they
don't
advertise
the
previous
prefix,
but
there
have
been
suggestions,
for
example
such
as,
in
this
particular
situation,
try
to
perform
some
kind
of
check
before
removing
the
addresses
or
the
prefixes
to
check
if
these
prefixes
are
valid
or
not.
J
Edek
klein
suggested,
for
example,
to
send
a
packet
to
your
same
address
but
direct
the
packet
to
the
next
hop
router.
So
if
the,
if
that
packet
bounces
back,
then
that's
an
indication
that
you
know
the
cpu
rather
still
has,
you
know,
still
considers
the
prefix
to
be
there
in
a
sense,
open,
open
received
of
arrays
with
other
PA
OS.
We
might
want
to
do
something
about
this.
J
What
currently
in
the
IDE
is
to
first
of
all,
UNPROFOR
the
the
addresses
and
then
to
remove
them,
but
there
are
other
things
that
are
possible,
such
as,
for
example,
check
with
a
router
if
the
prefix
is
still
there
or
not
all
the
things
that
might
be
of
help.
For
example,
RFC
48
61
says
that
you
shouldn't
honor
pios
or
the
lifetime
in
particular,
not
the
PIO
as
a
whole.
J
J
J
Another
thing
that
we
discuss
in
the
document
has
to
do
with
the
lifetime
of
the
prefix
information
options.
For
example,
if
you
look
up
the
default
lifetimes,
they
are
normally
in
the
order
of
one
month,
okay
and
in
the
context
of
RFC
a
t28.
If
I
remember
correctly,
for
multi
prefix
networks,
the
idea
is
normally
that
you'd
somehow
tie
each
prefix
to
the
router
that
advertised
it.
Why?
J
Because,
if
you
have
many
routers
and
you're
using
many
prefixes
on
the
same
network,
if
you
just
send
packets
from
a
prefix
to
some
random
router,
they
are
likely
to
be
a
grace
filter.
So
one
of
the
things
we
discuss
in
the
document
is
to
cut
the
lifetime
of
the
pls
to
the
router
lifetime,
and
the
current
version
of
the
idea
also
suggests
sending
more
freaking
arrays,
which,
based
on
discussion
among
a
number
of
folks,
it's
a
no-go,
but
since
it's
in
D
ID
I
mention
it
I'm
mentioning
this.
In
this
slide
comments.
AE
Tim
Berners
UNH
Iowa,
so
well
my
one
question
about
this.
Forty
eight
sixty
one
allows
for
invalidating
lifetimes
that
are
less
than
two
hours,
so
everything
we
tests.
You
know
we
give
it
a
lifetime,
it's
less
than
two
hours.
If
you
send
it
0,
it
will
invalidate
it
right.
It's
only
when
you
send
at
lifetimes
greater
than
two
hours
that
it
won't,
let
you
drop
it
to
directly
to
zero
right.
AE
So
some
people
for
flashier
a
numbering
basically
drop
their
prefix
lifetimes
the
less
than
two
hours
and
then
they
can
invalidate
all
of
the
all
of
those
rules
that
have
to
do
with
lifetime
are
all
based
around
the
two
hour.
If
it's
longer
than
two
hours,
if
it's
shorter
than
two
hours,
you
can
just
invalidate
it
using
slack
only.
AE
Think
it's
both
I'd
have
to
go
back
and
look,
but
my
memory
of
this
is
that
it's
both
lifetimes
that,
if
they're
less
than
two
hours,
you
can
wipe
it
out
right.
So
this
is
to
prevent
the
deal
here
is
for
denial
of
service
attack.
You
just
have
to
set
it
higher
than
two
like
two
hours
and
then
you
won't
run
into
this
problem.
AE
No,
what
happens
with
the
if
you
set
it
for
more
than
two
hours
and
then
you
give
it
a
value
of
let's
say
five
seconds:
it'll
drop
it
to
two
hours.
So
if
you
had
it
set
to
twelve
hours
and
then
you
decided
to
drop
it,
you
send
it
five
seconds,
it
will
drop
it
to
two
hours.
In
some
cases,
some
of
the
implementations
will
do
that.
Okay,.
AE
AF
Sorry
Richard
Patterson.
On
that
note
it's
so
we
already
have
preferred
lifetime.
So
I
think
that's
what
the
document
says
around
less
than
two
hours
so
fell.
A
lifetime
cannot
be
reduced
below
two
hours,
but
the
preferred
lifetime
can
so
with
with
sending
preferred
lifetime
of
0.
We
can
deprecated
the
addresses
and
that
mostly
solves
this
problem.
What
I
think
the
suggestion
to
adapt
48.61
to
allow
valid
lifetime
zero?
AF
The
only
problem
that
that
solves
is
the
one
you
mentioned
about
having
too
many
hairdressers
in
the
deprecated
State
bound
to
the
interface
so
for
hosts
that
have
too
many
the
valid
lifetime
would
solve
that.
But
that's
the
only
thing
it
was.
That
was
the
only
thing
that
will
solve
them
can't
already
solved
with
preferred
lifetime.
C
V
Andrew
McGregor
on
the
reduce
pio
lifetimes
I,
don't
recall
whether
there
is
anywhere
in
the
air
see
in
any
RFC
that
it
says
that
if
you
are
redistributing
a
prefix
that
you
have
learned
through
either
slack
or
DHCP,
that
you
should
set
its
lifetime
to
somewhat
less
than
half
of
the
lifetime
of
the
lease
you
have
on
it.
But
it
really
should.
V
J
V
AA
I
Jim
Joan
yeah,
just
to
echo
what
Richard
said
at
the
mic
just
now.
Also,
we
idea
remember
many
many
years
ago
when
we
had
the
common
problem
of
hosts
forming
a
six
to
four
address
from
Microsoft
address,
sharing
the
people.
Turning
that
on
and
not
realizing
the
impact
on
the
v6
network,
we
had
a
little
demon
that
sat
on
the
network,
basically
sent
out
Ras
with
zero
preferred
life
times.
Essentially
deprecated
those
things
I
mean
principle.
You
could
use
that
kind
of
thing
here,
but
it'd
be
a
bit
of
a
hat.
I
Can
be
you
never
know
where
there's
another
router.
That's
issuing
these
things.
You
could
do
something
where,
if
you
saw
a
packet
with
a
certain
source
address
to
say:
oh,
that's,
no
longer
a
valid
source
and
try
and
deprecated
it,
but
I
think
the
problem
here
is:
there's
lots
of
things
you
could
do.
That
would
be
pretty
hacky.
I
That's
there's
some
heuristics!
You
can
apply
and
there's
a
one
end.
This
heuristics
at
the
other
end,
there's
hacky
and
I'm
just
a
little
bit
nervous
that
there's
going
to
be
some
very
more
hacky.
Things
proposed
here
that
are
gonna
cause
problems
beyond
their
the
worse
than
what
were
actually
trying
to
fix.
Well,.
J
J
I
J
The
other
thing
is
what
we
do,
even
in
what
we
have
in
dedi.
Is
we
only
let's
say,
I'm,
prefer
or
or
remove
the
address
if
it's
being
advertised
by
that
single
router?
So
we
are
considering
the
case
in
which
multiple
routers
are
advertising
the
same
prefix.
In
that
case,
what
we
do
is
we
kind
of
like
disassociate
the
prefix
with
that
specific
router,
but
that
doesn't
mean
that
we
are
removing
the
address.
So
we
try
to
accommodate
the
case
where
the
same
prefix
is
being
advertised
by
multiple
routers.
H
Journaling
Cova,
so
yeah
I'm
also
been
concerned
that
we
apply
and
kind
of
hike
a
workaround
to
deal
with
broken
routers
or
administrative.
Miss
configuration
so
I
think
it's
a
bit
to
have
a
solution,
especially
taking
into
account
that
completely
changes
logic
of
processing
erase
when
you,
when
you
do
not
receive
some
information,
it
does
not
mean
it's
active
anymore,
so
you
basically
suggesting
totally
changing
the
logic.
So
I
think
that
changing
the
defaults
of
record
anyway
at
lifetimes
totally
does
make
sense.
H
I
believe
we
actually
should
have
done
it
long
time
ago,
because
seven
days
and
one
months
it's
like
doesn't
make
any
sense
from
operational
perspective.
I
believe
it
should
be
something
similar,
so
preferred
lifetime
by
default
should
be
similar
to
router
lifetime
avoided
lifetime
should
be
I,
don't
know,
twice
preferred
lifetime,
or
something
like
that.
So
it's
definitely
shouldn't
be
a
month,
and
this
I
believe
would
solve
most
of
the
problems.
H
We
should
not
actually
introduce
any
upper
limit
because
you
say
in
copter
outer
lifetime
in
data
center
environment
I
might
have
one
week
preferred
lifetime,
because
even
with
my
router
disappears,
I
still
might
want
to
have
online
communication.
So
I
think
we
definitely
need
to
change
defaults.
It
would
help
regarding
the
problem
of
not
being
able
to
talk
to
unlink
prefix
after
in
ambient
I'm.
Not
surely
not
sure
how
big
is
the
problem
for
home
networks
you'll
most
likely
do
not
talk
to
your
old
prefix
anyway,
much
right,
so
I.
H
Don't
think
we
really
need
to
tweak
the
protocol
to
work
around
that
issue
and
another
thing
shall
we
think
about
something
like
hey
Bibles,
for
source
addresses
and
if
you
have
two
other
addresses
from
different
prefixes,
you
might
need
you
might
try
to
do
kind
of
head
payables
and
see
which
one
works
and
use
that
one.
It's
actually
also
might
help.
Thinking.
P
Is
it
fixing
these
routers
so
that
they
behave
better
and
and
is
that
something
that
we
should
write
down
sort
of
rules,
and
if
we
do
will
they
actually
be
updated,
as
opposed
to
saying
oh,
let's
figure
out
some
workaround
hacky
or
not
where
the
host
can
actually
be
more
resilient
towards
those
or
are
we
gonna
end
up
doing
both
of
them
to
deal
with
this
stuff?
It's
not
clear
how
much
sort
of
energy
to
put
into
this
stuff
and
where
people
are
likely
to
fix
their
implementations.
P
AG
E
So
Tim,
do
you
want
the
last
comments?
Just
just
one
thing
that
Fernando
and
I
spoke
with
each
other
about
before
this
session?
Was
that
since
there's
been
so
much
interest
in
his
draft,
we
could
use
the
Wednesday
time
for
the
people
interested
in
meeting
the
smaller
room
and
talk
this
out
as
well.
I
think
you
know
phenomenal.
You
could
send
an
invite
for
that.
I
think
that's!
Thirteen!
I
Attention,
I
was
just
gonna
say:
maybe
we
can
tease
out
what
could
be
done
here
into
at
least
three
categories,
one
of
just
best
practices
and
recommendations
for
operators.
One
is
sort
of
what
implementers
might
do
and
the
third
one
is:
are
there
actual
changes
to
existing
specifications
that
are
needed
so
maybe
trying
to
think
of
the
different
categories
of
things
that
can
be
done?
Name
yeah,.
E
AB
AB
It
started
about
one
and
a
half
years
ago,
so
this
I
have
presented
it
earlier
at
six
men
at
this
cup
of
times,
and
also
a
couple
of
times
as
spraying,
so
I
believe
the
body
is
very,
very
aware
of
the
work
and
at
the
moment
we
there
are
deployment
that
exists,
and
there
is
also
a
draft
that
was
published
by
Satoru
this
morning,
and
that
was
regarding
former
update
to
these
deployments.
So
this
draft
has
been
deployed,
at
least
in
multiple
networks,
and
additional
deployments
are
coming
so
from
implementation
point
of
view.
AB
In
terms
of
summary
of
the
draft
at
the
moment,
is
it
basically
just
reuses
the
existing
ICMP
mechanism
for
use
cases
of
onn?
In
a
service
six
network,
it
also
defines
the
service
flags
obeyed.
The
opiate
was
initially
defined
in
the
SRS
Draft,
but
as
part
of
the
comments
during
last
call,
this
got
moved
out
of
resides
us,
and
this
draft
actually
define
it
exit
at
the
exact
same
location,
because
there
are
Hardware
implementation.
AB
So,
for
that
matter
it
is
really
up
decision
on
the
local
said.
The
definition
of
the
locus
said
would
know
whether
the
locus
said
is
able
to
or
should,
process
the
own
n
TLV
and
in
if
the
local
set
is
such
that
the
node
supports
it,
and
it
is
defined
that
way
to
look
at
will
be
then
the
look
up
to
the
TLD
will
happen.
AB
So
this
is
as
opposed
to
any
other
option
that
exists
through
either
destination
option
on
hop
hop,
and
this
is
why
it's
very
important
to
keep
that
TLV
and
the
use
case
for
the
tail
v
is
properly
defined.
Here
there
was
a
discussion
to
that
effect
earlier
from
next
step
because
of
the
multiple
deployment
and
probably
a
status
like
the
six
men
to
adopt
this
job.
AB
There
has
been
some
discussion
whether
this
block
belong
to
six
men
or
spring,
but
I
think
is
very
clear
that
this
is
really
in
its
expand
because
of
the
OPA
designation,
because
the
TL
we
use
case.
So
we
really
believe
that
this
is
in
six
men.
I,
don't
know
if
years
had
chance
to
talk
about
that,
but
I
mean
I.
Think
that's
I
think
pretty
clear.
AB
So
I
really
like
the
working
of
chair
to
a
start
at
option
for
poll
and
asked
asked
the
room
in
terms
of
the
interests
in
in
taking
on
this
particular
taking
on
this
world
and
then
once
the
working
would
take
on
this
word,
then
we
start
working
on
it
in
a
collaborative
fashion,
more
cooperative
fashion
and
address
address
your
comments.
Okay,.
E
As
we
have
discussed
that
a
little
bit
and
I
think
we'll
hold
off
with
any
other
draft
and
we'd
finished
the
bass
segment
routing
document,
and
then
we
can
do
another
option,
call
on
the
mailing
list
when,
when
that's
that's
done
so
thank
you.
Thank
you
so
far,
and
traditionally
we
would
have
said,
see
you
in
Montreal,
but
since
we
now
have
two
sessions,
we'll
see
you
on
Friday
and
the
blue
sheets.
Please
can
you
pass
those
forward?
Please.