►
From YouTube: IETF102-6MAN-20180716-0930
Description
6MAN meeting session at IETF102
2018/07/16 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
B
C
E
B
F
B
D
E
D
D
H
H
J
G
J
Hdm
segments
in
the
ip
layer,
which
is
basically
why
they
say
this,
is
not
that
big
of
a
deal,
but
we
have
to
run
about
a
working
group
because
the
original
draft
had
an
easy
ship.
I
don't
know
if
anyone
feels
strongly
about
this
being
mastership
would
be
great
if
anybody
feels
super
strong.
Otherwise
I
think
we're
going
to
leave
it
as
it
should
unless
and
that's
what
we
sort
of
that's
what
we
passed
by
the
weaponry
the
first
time,
but
if
people
feel
really
strongly
the
transport
people
feel
strongly
about
this.
H
H
H
All
right,
and
then
we
have
the
documents
of
interest
there
isn't
really
much
to
update
here.
From
what's
been
said
on
the
mailing
list,
I
believe
it's
in
suresh's
hands
to
discuss
with
the
ip
wave
working
group
to
to
see
what
the
conclusion
will
be,
but
there
will
be
we'll
take
this
back
into
six
man
when,
when
some
of
the
issues
that
was
raised
here
have
been
have
been
resolved
so
see
how
this
one
goes,
but
we'll
keep
an
eye
on
it
for
sure.
K
I'm
not
sure
how
that
goes
back
in
so
we'll
keep
it
at
it
right.
Good
morning,
everyone
we
have
40
minutes
for
this
discussion
on
segment.
Writing
header,
I'm
going
to
go
through
the
presentation.
It's
we're
going
to
have
maybe
10
15
minutes
or
so
at
the
end
of
this
for
discussion.
If
anyone
wants
to
come
up
with
the
mic
event
at
that
point,
I'm
sure
we'll
have
lots
of
folks
lining
up
our
us
folks
just
say
their
comments
till
the
end.
K
K
Through
all
that,
today,
there's
been
a
very
large
group
of
contributors
and
collaborators,
not
to
mention
those
most
recently
commenting
on
the
list
and
providing
their
feedback,
providing
insights,
providing
texts
and
opening
and
closing
issues.
So
thank
you
to
the
collaborators
we've
had
in
the
past
and
the
new
contributors
and
collaborators
that
we
had
during
the
last
call
your.
H
K
H
K
Added
railway
into
here
when
it
implements
the
sr,
header
and
hmac
as
of
actually
414,
I
believe
the
410
one
didn't
cisco
has
the
srh
implemented
in
the
two
oscillators
across
xc
and
xr
fdio
vpp
released
in
1704
april
of
last
year
bell.
Canada
barefoot
had
come
up
with
a
p4
implementation
in
may
of
2017..
K
Huawei
has
three
platforms
on
the
go
with
running
codes
working
on
those
three
platforms
and
junior
had
some
prototype
implementations.
As
of
the
last
ietf,
we're
keeping
track
of
interoperability
in
spring
slv6
interrupt.
That
document
has
not
been
updated
since
march,
but
as
additional
intro
operations
get
proven,
we'll
update
that
document.
So
whenever
that
dot's
updated
we'll
send
it
out
to
the
six-man
group
as
well.
K
All
right
so
today,
what's
our
agenda
we'll
go
through
our
last
call
update
we'll
go
through
changes
from
revision,
10
to
14
and
there's
been
a
lot
of
them.
Most
of
the
document
has
seen
significant
rewrites
we'll
go
through
the
last
call
issues
what
we've
closed
and
what
still
remains
open
and
we'll
cover
our
next
steps
and
where
we
plan
on
taking
this
document
based
on
the
working
group
feedback
so
far
and
based
on
the
open
issues.
K
It's
resulted
in
actually,
I
have
130
hits
and
closer
to
170
emails
on
the
list.
I
think
that's
more
than
one
per
day,
there's
been
a
lot
of
good
discussion,
debate
and
feedback
clarifications.
Example
texts
lots
of
stuff
going
on
on
the
list.
So
thanks
folks,
for
keeping
that
up,
we've
had
four
vision
versions
of
the
drafts,
which
many
people
have
reviewed
and
quite
a
comment
on.
It's
resulted
in
34
issues
closed
with
13
issues
remaining
open
and
I'll.
K
To
14.
the
first
thing
you
notice,
when
you
open
revision
14,
is
that
the
introduction
section
one
and
two
have
gone
from
four
or
five
pages
down
to
a
single
page.
There
was
a
great
deal
of
text
in
there
that
folks
had
commented
on
as
contradicting
itself
for
contradicting
other
sections
of
the
graph.
K
K
The
iets-3
segment
writing
mpos
is
the
mqs
data,
plane,
implementation
or
architecture.
I
should
say
of
the
segment
loading
architecture
and
it
obviously
has
a
dependency
on
the
second
loading
architecture
on
a
dependency
on
rfc
3032,
which
is
the
mpls
label
stacking
rfc,
and
you
can
see
the
parallel
here
between
the
mpls
and
ipv6
document
map.
So
the
ipv6
data
plan
implemented
by
this
draft
is
of
course
dependent
on
the
second
voting
architecture.
K
The
draft
fifi
spring
srv6
network
programming
is
the
srv6
architecture
draft
for
the
srv6
data
plane,
implementation
of
segment
writing
architecture.
Now
it
is
dependent
on
the
sr
header,
but
there's
no
dependency
on
from
the
sr
header
back
into
graphic
spring
srv6
network
programming.
The
reference
in
the
draft
is
information,
lonely.
K
K
H
L
K
K
K
So
we'll
leave
other
drafts
to
define
how
those
tlds
would
be
used
or
if
they
will
be
used
so
they've
been
removed
from
the
sr
header.
The
nsh
tlb
has
been
moved
out
to
the
draft
c
cloud
spring
sr
service
programming,
they've
accepted
the
definition
of
that
tlv
and
I'm
moving
forward
with
that
definition
and
and
the
use
cases
around
it.
K
After
the
sr
header
and
tld
definition,
we
come
to
a
section
in
the
draft
which
is
the
describes
a
few
different
node
types.
So
we
define
a
source
node,
a
transit
node
and
as
that's
our
endpoint
node
right
and
the
source
networks
definition
is
any
node
that
originates
an
ipv6
packet
with
a
segment
in
the
destination
address
of
the
ipv6.
K
K
The
transit
node
is
a
node
before
it's
an
ipv6
packet
where
the
destination
is
a
locally
configured
address,
or
a
segment
as
the
same
as
any
other
transit
node
for
ipv6.
Today,
the
sr
segment
endpoint
node,
is
any
node
that
receives
an
ipv6
packet
or
the
destination
address
of
the
packet
is
locally
configured
as
a
segment.
Okay-
and
this
is
this-
is
the
node
where.
H
K
It
was
important
to
define
the
three
note
types,
so
we
can
define
back
at
processing
up
those
note
types
and
by
by
combining
the
different
areas
of
the
draft
where
we
have
kind
of
spread
out
this
packet
processing
into
processing.
At
these
three
node
types,
an
implementer
can
now
go
through
and
and
see
exactly
what
they
need
to
implement
at
a
source,
node
versus
an
endpoint
node.
K
After
processing
at
a
sr
segment,
endpoint
node
really
comes
down
to
the
first
two
entries
in
in
these
bullets,
so
at
sr
segment,
endpoint
node.
We
define
an
example
processing
of
a
fib
entry,
so
we
look
up
a
destination
address
for
packet
and
we
find
it
we're
not
specifically
limiting
to
limiting
and
implementation
to
to
to
to
this
particular
design.
K
Implementations
may
be
able
to
to
come
up
with
other
designs
as
to
how
they
they
want
to
process
sids,
but
this
gives
them
the
logic
that
needs
to
be
implemented.
So
when
we
do
match
a
destination
address
to
a
locally
instantiated
srv6
sid,
we
have
a
section
clearly
in
the
draft.
Now
that
defines
what
the
processing
needs
to
be.
At
that
point,
and
when
we
match
that
destination
address
to
a
local
interface,
not
not
configured
as
an
srv6
sid,
then
we
have
a
section
that
defines
exactly
what
the
processing
is.
K
Okay
for
the
srv6
ncd,
we've
pulled
together.
Several
portions
of
the
document
that
well,
where
the
end
processing
was,
was
kind
of
spread
out
over
several
portions
and
we've
combined
them
all
into
section.
431
of
the
document,
section
431
defines
just
the
end.
Sid
behavior
we
previously
defined
an
n.x
in
behavior,
which
folks
might
recall,
was
a
segment
that,
when
present,
would
forward
a
packet
out
a
particular
interface
toward
a
particular
next
hop.
K
K
There's
a
set
of
illustrations
that
define
and
give
examples
of
packet
processing
at
various
nodes.
So
it
has
our
source,
node,
transit,
node
and
endpoint
nodes,
and
we
cover
off
two
examples
for
intradomain,
so
traffic
between,
for
example,
mode,
eight
and
nine.
In
this
little
diagram
within
the
sr
domain,
it's
traffic
solely
within
the
sr
domain
and
traffic
that
traverses
the
sr
domain
from
node
1
to
node
2,
where
node,
3
and
4
are
involved
in
inserting
and
removing
an
outer
ip
header
and,
as
our
header.
K
H
K
K
K
Okay,
so
so
on
the
edge
filtering,
we
have
three
issues
remaining
around
the
acls
and
there's
discussion
on
the
list
regarding
how
those
acls
are
are
created,
what
information
they
contain,
what
what
are
the
acs
within
those
acls
and
then
how
do
we
use
those
to
determine
when
to
inspect
that
hmac?
So
if
anyone
wants
to
come
up-
and
you
know
remind
us
about
what
those
are
or
give
any
further
comments
on
them-
we'll
welcome
that
at
this
time.
G
G
K
K
On
the
tag
fields,
we
close
off
a
number
of
issues
related
to
tag,
but
I
think
we
still
have
more
issues
that
need
to
be
closed
off
here.
37
and
61
in
particular,
and
I
believe
the
action
there
is
for
us
to
more
fully
define
what
that
tag
is
and
how
it's
processed,
when
it's,
when
it's
created,
why
it's
created
and
how
it's
handled
at
an
end,
point.
M
Trying
to
use
the
detect
field-
and
I
think
that's
the
this
greatest
way
to
go
forward-
is
just
to
define
that
field
as
unassigned
bits
and
then
move
the
the
draft
as
it
is,
because
there's
no.
Unless
you
come
with
a
particular
use
case
in
which
we
we
are
clear
about
the
usage
of
this
one.
In
addition
to
what
you
have
already
in
the
ips
expected
itself
to
to
classify
and
to
differentiate
the
behavior
of
the
treatment
of
the
buckets
themselves,
I
think
that's.
M
K
Yeah
and
folks
have
recommended
that
on
the
list
too.
Personally,
I
think
it's
probably
worth
spending
some
time
and
and
trying
to
make
sure
we
define
what
those
you
know
in
into
an
acceptable
degree.
What
the
what
the
tag
is,
I
don't
think
it's
gonna
take
forever,
but
certainly,
if
that's,
if
what
you
suggest
needs
to
be
done
in
the
end,
then
then
we
can
go
that
direction.
K
E
Okay,
mr
robin
from
quality,
I
would
like
to
add
some
information
about
the
implementation
under
the
inhalability
test.
So
now,
until
now,
there
are
several
the
implementation
about
the
srv6
and
the
srh.
So
now
that's
in
fact
based
on.
As
far
as
I
know,
some
of
this,
the
interability
test
has
been
done
through
the
vendors
under
the
nissa
and
experimental
tests.
So
I
think
that
and
now
that
the
more
importability
tests
will
be
done
in
the
coming
months,
so
that's
based
on
the
interability
test.
E
K
Yeah,
so
definitely
more,
you
know
of
those
implementers
who
are
implementing.
You
know
what
kind
of
repeat
robin
said:
there's
more
interoperability,
testing
and
more
documentation
of
that
is
certainly
appreciated.
So
anyone
with
implementations
that
are
interested
in
interoperability
testing-
I
I
guess
we
need
to
make
sure
we
might
as
well
send
those
out
to
the
list
as
well
or
contact
the
individuals
with
implementations.
K
K
K
K
Oh
thanks,
all
right,
so
I
missed
one
here
we're
now
six,
unless
that's
67
was
that
67,
that's:
okay,
okay,
okay!
So
there's
there's
a
new
ticket
open
for
insertion
deletion.
If
folks
didn't
hear
that
the
optional
processing
for
local
policy
as
well
needs
to
be
defined
in
the
draft,
we
said
it's
optional
per
policy,
there's
an
action
at
the
end
here
to
define
what
the
data
model
is
for
that
and
that's
in
our
next
steps.
G
There's
a
good
discussion
going
on
about
why
tlvs
are
not
implemented
in
destination
options
before
the
routing.
Yet,
oh
by
the
way,
ron,
banik
and
jennifer,
we
should
probably
come
to
conclusion
on
that
and
document
why
we
made
the
decision
it
can
go
off
in
an
appendix
someplace
yeah.
I
think
you're
right
now.
M
K
K
All
right,
so,
where
do
we
go
next
and
how
are
we
for
time?
Okay,
all
right,
so
this,
I
think,
covers
off
what
would
what
was
discussed
at
the
mic
tags.
We
need
to
document
usage
tlvs.
We
need
more
information
on
tlb
processing
text
and
usage
text
and
clarification,
as
ron
had
mentioned
on
the
hmac.
This
is
something
I
didn't
talk
about
in
the
changes
between
10
and
14.
K
We
as
a
working
group
and
we
as
a
group
of
authors,
have
not
spent
a
whole
lot
of
time
in
that
security
section.
The
people
who
have
have
noted
hey,
there's
some
problems
in
there
that
need
to
be
fixed.
So
I
think
the
next
step
on
the
security
section
is
that
we
need
to
do
a
deep
review
of
that
and
probably
rewrite
that
security
section.
So
it's
much
more
self-consistent
and
we
pull
out
the
hmac
processing
in
the
security
considerations.
K
K
I
believe
revision
10
of
the
draft,
the
need
for
a
management
section
which
I
deleted
in
revision,
11
saying
well,
it
wasn't
required
that
we
had
a
management
section,
but
now,
with
the
acl
discussion
and
the
discussion
around
what
the
hmac
the
data
the
hmac
actually
needs,
I
think
we
do
need
to
add
that
management
section
back
into
the
doc,
at
least
to
define
the
data
model
for
cns
for
srh
insertion,
srh
insertion
at
source.
What
data
is
needed
in
order
to
build
that
sr
header?
K
E
K
K
E
Has
been
done
several
of
the
working
groups,
for
example
in
the
slc
working
groups,
the
inner
side
of
their
qrs
and
also
in
the
iom
in
the
ikpm,
and
there's
also
the
qrs
in
the
llm
header.
So
we
think
that
is
also
not
the
thing
is
the
programming
in
the
following
week
is
optimizing
the
solutions
for
the
future
so
that
we
would
like
that
for
the
srh
we
can.
This
is
the
chance
so
that
we
think
that
we
give
this
possibility
for
the
qre
for
the
flexible.
K
G
K
D
I
mean
I
think
this:
will
it's
not
just
this
work,
but
I
think
that's
something
that
needs
to
be
coordinated.
I
don't
think
we
know
exactly
know
what
the
right
answer
is.
The
other
comment
I
wanted
to
make.
I
think
this
was
in
the
document
statuses.
I
mean
given
the
long
discussion
and
number
of
changes
when
we
think
all
the
open
issues
are
done.
We
will
do
another.
A
work
group
last
call
because
we,
I
think
we
want
the
work
to
read
the
new
document,
which
is
quite
different
from
the
one
we
originally
did.
L
L
L
When
it's
zero,
it
basically
says
this
is
not
an
ipv6
only
link,
and
that,
of
course,
is
the
default
state
in
existing
code,
existing
implementations
when
it's
set
to
one.
It
says
this
is
an
ipv69
link
and
the
draft
normatively
updates
the
flags
registry
to
the
and
technically,
we
have
to
say
we're
requesting
this
bit
from.
You
know
we're
requesting
them
to
call
it
sex,
but
we
think
that
they'd
probably
do
it.
L
H
M
M
L
L
J
L
N
George
michaelson
from
ap
nick
brian,
I
like
the
idea
right.
I'm
not
I'm
not
opposed
to
an
anti-evil
bit
and
I'm
not
trying
to
say
it's
a
bad
idea,
but
the
attack
vectors
that
come
to
mind
when
you
think
about
evil
bits
and
non-evil
bits
of
the
triviality
of
it
being
flipped
by
an
intermediary
in
the
consequence.
N
Netware
or
decknet
was
implicitly
live
at
some
low
level
interface
binding
on
a
host
because
of
the
legacy
of
what
shipped
in
an
os
and
the
risk
that
someone
on
a
switching
fabric
with
no
routing
intent
turns
up
services
that
will
provide
the
naming
binding
or
the
file
service
binding
or
the
printer
binding,
and
because
these
low-level
primitives
are
live
on
that
os.
They
magically
glom
onto
it
and
suddenly
you've
got
this
packet
flows
happening
on
your
switching
fabric,
because
someone
has
turned
on
netware.
N
Even
though
you,
the
network
administrator,
had
no
intent
of
running
network
and
we
kind
of
we
kind
of
worked
through
those
risks,
we
didn't
have
to
build
into
protocols,
never
do
network
bits
to
handle
that
we
just
allowed
them
to
age
out.
So
I
I
know
it's
kind
of
arguing
in
the
odd
sense,
but
why
do
we
need
an
anti-evil
bit?
N
J
Lindsey
gotti,
I
think
you
should
clarify
what
it
means
when
the
lifetime
is
zero
like
if
I
have
a
reader,
that's
on
there's
only
one
reader
on
linkedin.
It
says
lifetime,
it's
already
lifetime
of
zero
because
it
has
no
uplink
the
flag
is
basically,
I
don't
even
know
what
it
means.
It
says
the
flag
is
valid
for
zero
seconds.
I
don't
know
what
that
means.
O
Lee
howard,
I
want
to
respond
to
george,
my
memory
of
of
netware
and
ipx
is
well,
I
guess,
as
old
as
everyone
else's.
In
my
recollection,
I
spent
I
seem
to
remember
spending
an
awful
lot
of
time
trying
to
manage
to
get
drivers
installed
for
those
protocols
and
they
were
never
installed
on
clients
that
I
used
by
default.
Ipv4
is
installed
on
practically
every
client.
I
touch
by
default,
and
so
this
is
changing
default
behaviors
that
I
don't
think
we
had
when
we
had
to
do
when
we
dealt
with
other
things.
O
Deck
net
is
a
slightly
different
case
for
operating
systems
that
ran.
You
know
that
operating
system
that
was
probably
the
developed
behavior,
but
I
think
we
were
able
to
change
that
much
more
manually
because
you
had
administrators
involved
in
setting
up
networking
protocols
at
the
time.
I
think
that's
the
fundamental
difference
that
george
is
looking
for.
P
Genuine
goal
yeah
it's
to
george.
I
actually
think
it
could
prevent
some
attack
vectors
because,
let's
say
in
five
years,
people
might
10
years.
I
don't
know
at
some
time.
People
might
do
not
want
to
run
before,
and
so
I
do
people
might
forget
to
put
all
these
dhcp
snooping
converters,
this
art
spoof
prevention
stuff.
So
this
could
tell
how
this
is
with
vcx
only
network,
so
don't
even
try
to
do
before.
So
there
is
less
risk
of
getting
some
random
dhcp
server
of
your
network
right,
potentially.
N
P
L
J
Q
E
H
H
And
if
no
one
objects,
I
can't
see
the
microphone
line,
so
I
assume
it's
empty
then
yes,
yeah.
So
let's
do
that.
There's
clearly
a
few
issues
that
needs
to
be
thought
through
a
little
bit
more
and
then
or
at
least
get
a
more
common
agreement
on.
But
I
think
we
could
do
that
as
a
as
a
working
group
called.
R
H
R
R
4941,
since
it
its
publication
is
first
one,
it
prevents
the
use
of
only
temporary
addresses
because
they
are
generated
in
addition
to
the
stable
ones.
The
second
one
is
that
it
recommends
the
use
of
the
same
interface
id
for
multiple
prefixes.
So
if
you
configure
multiple
addresses
for
multiple
prefixes
on
the
same
network,
you'd
end
up
using
the
same
interface
id
for
them,
which
obviously
allows
correlation
correlation
between
the
activities
of
what
you
do
with
each
of
those
addresses.
R
R
So
what
we
did
in
4941,
let's
say
from
a
technical
point
of
view.
Besides
miscellaneous
edits,
we
replaced
the
algorithm
for
generating
the
interface
ids
with
two
alternative
algorithms,
the
first
one
you
just
compute.
Whenever
you
need
to
come
up
with
a
interface
id,
you
just
you
know,
produce
a
random
number,
that's
what
we
mentioned
in
this
slide
as
random
interfaces
and
in
the
other
one.
R
Or
try
to
put
in
three
different
slides
some
issues
on
which
we
need
input
from
the
working
group.
First,
one
is
what
to
do
with
the
algorithms.
So
far
we
have
two
algorithms,
the
simple
randomization
one
and
the
one
that
parallels
or
it
that
is,
you
know,
based
on
the
same
function
as
seven
two.
Seventy
two,
seventeen.
R
As
you
know,
we
got
feedback
among
other
people
from
lorenzo
quality
and
he
suggested
to
improve
the
you
know
the
algorithm
that
we
have
217,
which
we
did,
but
there
were
other
companies
like.
What
do
you
recommend,
like
the
simple
randomization
one
just
provide
the
two
options
and
not
recommend
any
or
maybe
remove
the
ones
that
employ
a
similar
together?
R
R
H
S
R
R
R
R
R
R
R
H
D
R
J
H
R
I
mean
I'm
thinking
about
the
choice,
but
in
that
case
you
not
implement
41
41
anyway,
so
you
know
whether
the
on
or
off
by
default
doesn't
really
apply
to
you.
That's
what
I
mean.
So
you
don't
you?
Will
you
wouldn't
implement
41
4941?
So
you
don't
care
about
the
default
because
you
wouldn't
be
implementing
them
anyway.
H
R
If
we
want
to,
you
know
help
in
terms
of
user
privacy,
I
mean
the
user
is
not
going
to
turn
this
on
by
default
because
they
don't
care
about.
You
know
they
probably
don't
even
know
what
an
ip
fixed
address
is.
So
the
I
guess
the
question
here
is:
if
we
want
the
you
know
the
default
option
to
be
like,
let's
say,
privacy,
sensible
or
not,.
H
E
L
R
That's
true:
well,
there's
also
the
issue
that
there
can
be
some.
You
know
devices
for
first
hop
security.
That
might
not
like
the
fact
that
you
know
the
same
system
is
using
multiple
addresses,
but
I
think
that
in
all
of
these
cases
anyway,
that
behavior
would
be
contradicting
you
know
the
the
advisory
that
was
provided
that
was
generated
by
b6
ops
on
multiple
addresses
per
cop
per
house.
R
I
think
this
is
the
last
one.
If
I,
if
I
recall
correctly,
okay,
that's
the
this
is
the
last
one.
Sorry,
and
there
was
another
issue
that
you
know
essentially
what
we
you
know
what
we
say
in
the
in
the
document
to
others.
One
of
the
issues
that
I
you
know
that
I
mentioned
before
is
that
essentially
the
interface
it
is,
you
know,
should
not
only
change.
R
You
know
as
a
function
of
time,
but
also
as
a
result
of
privacy,
sensitive
events,
including
the
case
where
the
node
you
know
re
like
disconnects
and
reconnects
to
to
the
to
the
network,
and
I
think
it
was
brian
that
you
know
right
the
question
of
what
we
could
you
know
possibly
do
to.
You
know,
prevent
let's
say
a
minor
glitch
in
the
connection
to
the
same
network
from
producing
different
interface
identifiers.
R
I'm
not
sure,
if
there's
much
more
to
do
like
something
similar
to
what
we
did
for
7217,
which
was
to
use
like
dna.
If
I
remember
correctly,
like
you
know
it's
kind
of
like
it,
you
know
trying
to
find
a
way
to
detect
whether
you
are
reconnecting
to
the
same
network
or
not,
but
but
at
the
very
least
we
might
include.
I
guess
some
some
some
work
on
that.
D
I
I
Should
I
create
a
new
one
when
I
reattach,
if
you
reattach
to
the
same
bss,
whatever
right
on
wi-fi
and
you
still
have
the
same
mac
address,
because
that
didn't
change
underneath
you
well,
then
pick
the
same
one
right,
but
if
any
of
those
those
other
things
changed,
then
you
should
actually
regenerate
the
iid.
So
I
think
that's
spelling
that
out.
I
I
think
it
requires
some
care
to
go
through
the
actual
ordering.
In
terms
of
what
information
do
you
find
out
when,
when
you
attach
to
a
network
or
reattach
to
network,
so
make
sure
that
you
have
all
of
those
things
available
before
you
form
your
id
right,
particularly
for
the
link
but
but
just
trying
to
try
to
have.
R
R
From
that
point
of
view
for
addressing
this
issue,
it
might
make
sense
to
keep
the
algorithm
that
we
have
for
7217,
because
the
idea
of
you
know
whether
you
are
attaching
be
attacked
to
the
same
network
or
not
is
like
included
in
the
document,
because
there
is
any
identifier
so
which
can
be,
for
example,
the
ssid.
But
whereas.
R
You
know
72
ce,
the
algorithm
that
we
have
to
see
you
know
and
tweak
it
a
little
bit
so
that
you
know
just
because
the
time
changes
if
you
reattach
to
the
same
network.
You
know
you
know
the
same
id
is
produced,
that's
kind
of
like
what
we
do
with
that
algorithm
orthogonal
to
the
to
the
question
of
what
we
end
up
doing
you
know
with
the
algorithm,
so
I
guess
for
the
exhibition.
D
D
G
Juniper
networks-
and
I
have
three
drafts
to
show
you
in
the
three
drafts
I'm
going
to
ask
for
a
codification
of
four
destination
options,
so
they're
pretty
cut
and
dry
drafts.
All
these
presentations
will
be
explaining
why
I
want
these
four
destination
options.
The
first
one
is
the
vpn
context,
information
option.
G
G
G
G
G
So
we
arrive
at
the
egress
pe.
What
do
we
do?
We
receive
the
packet
from
the
pe.
We
remove
the
transport
tunnel
header,
we
remove
the
vpn
context,
information
and
then
we
do
something
depending
on
what
the
vpn
context
information
said.
For
instance,
we
might
forward
the
packet
to
a
specific
interface
to
the
right
destination
or
we
might
look
up
the
packet's
destination
in
the
right
vrf.
G
G
G
A
G
G
What
would
we
like
it
to
be
a
new
destination
option,
so
we're
just
moving
the
information
from
an
mpls
label
that
came
right
after
the
transport
ipv6
header
to
something
that's
inside
the
transport
ipv6
header?
What
does
this
new
option
look
like?
Well,
it
has
an
option
type
to
be
determined
by
anna.
G
K
Yeah
darren
dukes
from
cisco,
since
this
is
a
tlv,
basically
you're,
taking
the
mpls
label,
value
for
and
sticking
it
into
a
tlv.
How,
as
somebody
who's
in
blending
data
planes,
how?
How
would
your
data
plane,
then
you
know
you're
gonna
have
to
walk
that
tlv.
Are
you
gonna
say
well,
this
thing's
always
the
first
entry
in
the
tlv.
K
L
G
L
G
L
G
G
J
J
G
E
E
That
context
is,
is
transmitted
in
many
ways,
with
many
ietf
protocols,
lttp
back
in
the
early
days.
V2
did
it
with
a
combination
of
session
tunnel
id
and
then
later
with
v3
with
just
the
session
id
vmi
was
brought
up
gre.
Does
it
with
a
key,
sometimes
there's
every
vpn
has
some
sort
of
way
it
could
even
be
configured
in
the
source
desk.
G
E
G
E
G
G
D
G
G
Okay
ipv6
allows
fragmentation
at
the
source
node
only
so
a
source
node
has
two
things
that
it
can
do.
One
is
refrain
from
ever
sending
a
packet
bigger
than
1280,
which,
incidentally,
is
what
we
do
these
days
in
the
internet
for
the
most
part
and
the
other
is
to
maintain
a
running
estimate
of
the
pmtu
and
refrain
from
sending
packets
greater
than
that
estimate
and
right
now
we
have
two
tools
to
maintain
that
running
estimate,
pmtud
and
plpmtd.
G
G
The
source
sends
packets,
never
larger
than
the
pmtu
estimate,
but
possibly
larger
than
the
actual
pmtu.
When
a
packet's
larger
than
the
actual
pmtu
an
intermediate
node
can't
forward
it.
So
it
discards
the
packet
sends
an
icmp
ptb
back
to
the
source
and
the
source
updates.
Its
pmtu
estimate
will
rinse
and
wash
again
now,
let's
talk
about
how
pmtud
breaks
well,
when
the
network
can't
deliver
the
icmp
ptb
message
from
the
intermediate
node
to
the
source,
the
source
doesn't
update
its
pmtu
and
you
get
persistent
black
holes
now.
G
H
G
So
we
need
some
new
procedures
and
now
we're
going
to
talk
about
the
new
procedures,
an
upper
layer
protocol
is
going
to
send
the
packet,
so
he
marks
that
packet
as
being
truncation
eligible
when
an
intermediate
node
can't
forward
the
truncation
eligible
packet
because
of
an
empty
issue.
It
truncates
the
packet,
it
marks
it
as
being
truncated
and
it
forwards
the
packet
to
its
destination.
G
G
G
G
G
The
truncated
packet
option,
value
tbd,
iana
exact
bits
are
1-0.
That
means
if
the
destination
receives
a
truncated
packet
and
doesn't
understand
this,
it
drops
the
packet
and
sends
an
icmp
parameter
problem
back
to
the
source
and
again
the
change
bits
are
irrelevant
because
the
option
length
is
zero.
G
So
what
are
the
procedures
we
have?
The
source
node
sends
a
packet
with
the
truncation
eligible
set,
the
intermediate
node
attempts
to
forward
a
packet,
and
it
has
an
in
well
first.
Let's
say
it
attempts
to
forward
a
packet
and
it
doesn't
have
an
mtu
issue.
I'm
sorry
if
it
doesn't
have
an
mtu
issue.
It
just
forwards
it
because
it
doesn't
look
at
the
destination
options
at
all.
If
it
does
have
an
mtu
issue
and
it
recognizes
either
the
truncation
eligible
or
package
located
it
truncates.
G
G
If
the
packet's
not
eligible
for
truncation,
it
just
discards
the
packet
and
sends
an
icmp
ptb
back,
it's
the
legacy
behavior
the
destination
node
when
it
receives
a
packet
with
the
truncation
eligible
it
just
skips
over
it.
It
doesn't
make
a
difference,
and
it
does
this
whether
or
not
it
recognizes
it.
Yes,
the
packet
was
truncation
eligible,
but
it
wasn't
truncated.
G
However,
if
the
destination
node
receives
a
packet,
a
truncated
packet-
and
it
recognizes
it,
it
sends
an
icmp
pdb
to
the
source.
The
mtu
field
reflects
the
packet
length
and
by
the
by
default
it
discards
the
packet.
However,
a
upper
layer
protocol
can
register
for
delivery
of
truncated
packets.
It
might
want
to
do
that
because
it
might
want
to
know
the
metadata
it
might
want
to
know
how
long
the
packet
is.
So
that
way,
it
can
negotiate
things
like
mss
at
the
upper
level,
where.
G
J
D
D
G
D
G
G
F
P
O
Messages
from
intermediate
nodes,
either
because
of
its
own
security
policy
or
intermediate
security
policy.
That
seems
a
little
unlikely
to
me
that
it
would
have
that
much
information,
and
I
think
the
point
about
that.
The
fact
that
your
checks
on
the
match,
if
you
say
hey
the
upper
layer
protocols,
might
want
to
see
that
packet
anyway,
because
of
metadata.
That
sounds
like
an
opportunity
for
me
to
throw
packets
with
mismatching
checksums
at
you
and
see
what
makes
it
up
the
stack
well.
G
J
Lorenzo
yeah
similar
comment
just
quickly.
I
think
really
before
proceeding
with
something
like
this,
you
need
to
figure
out,
you
know.
Is
there
enough
incentive
for
the
source
node
to
ever
use
this,
and
it's
not
clear
to
me
at
all
that
there
is
because
it
might
be
if,
if
there's
no
benefit
to
the
source
node
of
being
able
to
use
this,
then
they're
not
going
to
use
it.
Yes,.
J
A
direct
benefit
to
themselves,
and
second,
if
this
doesn't
get
us
close
enough
to
100
it'll
fail
anyway
right
it.
So,
basically,
if
because
this
is
going
to
fail
some
percentage
of
the
time,
if
that
percentage
is
high
enough,
then
there's
no
there's
going
to
be
no
benefit
unless
you
have
yet
another
technology
that
doesn't
work
enough
enough
of
the
time
for
us
to
bother
with
it.
G
D
G
G
So
what
would
be
a
good
thing
to
do
to
figure
out
if
you're,
in
a
situation
where
either
of
those
aren't
going
to
make
it
well,
what
you
could
do
is
probe
the
network,
send
a
packet
with
an
unrecognized
option
whose
first
two
bits
are
one
zero
and
wait
to
see.
If
you
get
a
parameter
problem
message,
if
you
do,
then
the
network
does
everything
you
need.
If
you
don't
get
that
parameter
message,
either
the
probe
or
the
response,
the
icmp
response
was
dropped.
G
So,
okay,
let's
say
I
want
to
write
some
software
that
does
this
well,
I
have
to
pick
an
option
that
is
undefined
and
use
that
to
prove
the
network,
well,
which
option
id
should
I
use.
I
need
one,
that's
not
provide
defined
today,
it's
not
defined
to
borrow
and
it
will
never
be
defined
well.
The
only
way
to
do
that
is
to
define
one
and
make
sure
that
I
never
implement
it,
which
is
what
I'm
asking
for
I'm
asking
to
define
an
option.
G
G
G
The
use
case
I'll
skip
over
because
we're
out
of
time
and
again
asking
for
adoption,
but
since
the
other
two
are
waiting
for
adoption
and
this
is
to
solve.
Yes,
I
would
make
one
quick
observation,
which
is
that
if
you
use
the
same
flow
label,
someone
who's
doing
layer,
three
only
hashing
will
actually
hash
it
on
the
same
path
that
the
original
flow
actually
had.
Oh,
so
we
could
get
rid
of
the
yeah,
so
I
mean
there's
obviously
a
weird
vertical
change
there,
because
you're
just
reusing
the
flow
label.
P
Good
question,
so
you
need
to
somehow
record
the
information
that
this
destination
to
this
destination.
You
can
send
packets
with
destination
option
right.
Are
you
suggesting
to
keep
it
in
somewhere
in
the
destination
cache
like
an
mtu
and
verify
it
periodically
because
it
might
visit
right
now?
You
can
do
that
and
then
the
past
change.
Then
you
cannot
do
it
anymore.
G
H
G
J
J
No
rather
could
send
an
ra
with
a
zero
or
close
to
zero
valid
lifetime
and
cause
all
the
other
hosts
on
the
link
to
lose
their
v6
addresses
and
be
unable
to
talk
to
anyone
off
link,
okay,
so
there's
an
explicit
proviso
in
4862
to
reject
these
real
advertisements
unless
the
array
is
authenticated.
Okay,
now
there
are
a
lot
of
links
where
this
bus
vector
doesn't
exist.
J
Ipsec
tunnels,
pvp
links
where
there
is
no
sort
of
there's
no
possibility
for
another
node
to
be
on
the
same
link
cell
networks,
where
there's
only
one
reader
okay.
So
what
we're
trying
to
do
is
just
lift
this
restriction
on
those
types
of
links
where
it's
by
definition,
safe
note
that
it's
also
by
definition
safe
from
the
network
that
has
ra
guard,
but
that's
slightly
different,
because
the
host
doesn't
know
if
r-a-guard
is
is
on
or
not.
So
why
do
we
need
to
do
anything
at
all?
J
J
Another
case
is
the
the
new
mobility
modes
defined
by
5g
networks,
where
you
can
have
these
shorter-loved
ip
addresses
that
are
that
they're
not
back
holds
to
a
central
mobility
anchor
or
the
backhoe
to
a
mobility
anchor
that's
very
distributed
geographically,
so
that
when
you
move
around
you
get
these
ip
addresses
that
are
close
to
you.
They
have
lower
latency
and
they're
less
expensive
for
the
network
to
maintain.
So
so
that's
another
use
case.
J
J
If
you
do
have,
you
know,
don't
delete
your
only
global
address
on
this
network
or
don't
delete
your
only
aggressive
same
scope
on
this
network,
because,
maybe
that's
I
don't
know
we
could
delete
that
if,
if,
if
the
working
group
feels
that
that
should
be
deleted,
this
is
the
current
text
proposal,
I'm
sure
we
can
wordsmith
it.
There
have
been
a
couple
of,
like
I
said,
there's
been
some
discussion
on
the
list.
J
One
one
criticism
was
that
this
is
a
layering
relation
that
the
host,
like
slack,
should
be
implemented
at
layer
4
on
top
of
on
top
of
icmp.
We
don't
agree
with
that.
I
mean
if
you
have
to
write
a
slack
implementation.
You've
got
to
know
a
lot
of
stuff
about
the
link
you
need
to
know
if
it's
multicast
capable
you
need
to
know
the
mac
address.
J
J
Why
not
make
this
a
negotiated
flag
in
slack?
Well,
first
of
all,
you
have
a
downgrade
attack,
which
is
basically
you
know
we're
saying
this
is
an
evil
but
kind
of
thing
where,
if,
if
somebody
you
know,
if
somebody
wants
to
send
you
rogue
ra,
they
can
just
set
the
flag
first
saying.
Oh,
this
is
a
this
is
a
peer-to-peer
link,
but
this
is
a
point-to-point
link.
J
There
was
more
clarifications
necessary,
saying,
okay.
Well,
let's
say
that
we
for
convenience.
Let's
say
that
you
can't
use
this
option
on
ethernet,
which
of
course,
we
can't
and
that
regard
is
not
sufficient.
So
we're
gonna
add
these
to
the
text
of
the
draft
and
I
think
with
that.
I
don't
know
what
to
do
next.
I'm
here
you
can
throw
fruit
at
me.
E
There
are
several
configurations
one
could
be,
and
that
would
be
good
for
us,
but
there
is
a
vapor
router
that
connects
the
mobile
hosts
to
to
the
two
different
drivers,
and
in
that
case
that
does
work,
but
there's
also
a
configuration
where
you
don't
want
the
gateway
router.
But
you
want
to
connect
the
mobile
host
from
the
same
radio
to
two
routers,
and
in
that
case
this
doesn't
work.
J
J
So
as
for
sorcerer's
selection,
I
think
again,
if
you
definitely
if
you,
if
you
delete
all
the
addresses,
then
you
have
no
addresses
to
select,
and
so
the
the
dos
factor
you
know
on
on
a
broadcast
language
does
exist
right.
So
we
can't
just
write
that
off.
We
can't
just
delete
that
text,
I
mean
we
could
delete
that
text.
J
If
we
say
if
we
were
to
agree
that
we
don't
support
networks
that
don't
run
our
a-guard,
then
then
we
could
delete
that
text
and
in
fact
you
know,
I
think
you
know
when
ipv4
goes
away,
then
yeah.
Alright
gutter
is
pretty
much
presumed
to
be
there
by
definition.
Otherwise
things
are
broken,
and
so
we
don't
need
to
worry
about
it,
but
I
don't
know.
I
don't
know
that
there's
enough
consensus
to
say
well,
we
have
to
run
our
yard
anyway
and
so
we'll
just
delete
this
this
security
text.
P
Julian
questions,
I
don't
think
it's
about
default.
Address
selection
because
default
address
selection
applies
for
new
connections,
and
this
you
can
control
this
deprecation
by
setting
preferred
lifetime.
I
want
it
looks
like
what
aren't
you
trying
to
do
is
to
signal
for
existing
connections
just
stop
using
it.
You
cannot
use
that
address
anymore,
so
prefer
lifetime
router
withdrawal
room,
five,
five-
it
wouldn't
apply
here.
J
B
G
So
a
state,
stateless,
stateless,
auto
configuration
service.
We
know
that
ipv6
neighbor
discovery
supports
stateless
address,
auto
configuration
and
dhcpv6
is
a
separate
stateful
service.
So
the
goal
is
to
have
a
unified,
stateless,
stateful,
auto
configuration
service
that
provides
the
best
access
to
both.
G
G
So
then
routers
on
the
link
will
receive
the
option
and
forwarded
to
the
dhcp
v6
server.
The
dhcp
v6
server
then
processed
the
option,
as
as
a
dhcp,
v6
client
request
and
force
the
dhcd6
reply
to
the
client
via
the
router
and
then
routers
finally
include
the
dhcpv6
reply
in
an
option
in
the
unicast
router
advertisements.
G
So
the
benefits
of
this
is
that
we've
now
reduced
four
or
more
messages
into
just
two
there's
no
longer
any
need
for
examining
the
ra
m
o
bits
and
legacy
routers
that
do
not
recognize
the
option,
simply
ignore
it
and
the
end
result.
Is
you
get
a
single
unified
service
for
all
auto
configuration
purposes.
G
J
J
Both
were
well,
they
kind
of
went
down
in
flames,
but-
and
the
second
second
point
was
the
pi.
The
the
what
I
really
wanted
to
send
with
the
pio
x
bit
was
essentially
very
similar
to
the
signal
being
sent
by
the
zero
lifetime
ra
situation,
and
that
is,
you
have
exclusive
use
of
this
link.
There's
nobody
else
there,
it's
just
you
it's
just
you
and
the
router
you
and
the
routers
right,
one
client,
node
and
then
the
infrastructure.
J
J
So
I
my
intention
with
the
par
bit
was
to
make
something
usable
when
to
give
a
useful
indication
to
the
client
that
it
was
the
only
one
there
in
the
same
way
that
we
know
in
quotation
marks
on
the
3gpp
architecture,
that
when
we
get
a
slash
64
from
the
mobile
network,
it
is
in
fact
ours
and
not
anybody
else's.
And
so.
J
64
share
and
that
kind
of
thing
I
I
haven't,
I
haven't,
formed
an
opinion
for
against
anything
specifically
just
yet,
though,
thank
you
lorenzo
community
I
am
drunk.
This
is
actually
don't
actually
think
this
is
very
useful,
particularly
because
it
it
doesn't
actually
reduce
traffic
except
in
the
initial
exchange,
because
if
you
every
time
it
says
every
time
you.
J
To
your
dhp
is
a
polling
protocol
right
and
this
doesn't
get
rid
of
polling,
but
ra
is
a
push
protocol,
so
this
doesn't
get
rid
of
push.
So
you
basically
from
a
power
perspective
and
from
a
traffic
perspective.
You
don't
actually
save
much.
You
only
save
the
initial
exchange
rates
still
have
to
be
pushed
to
you
and
you
still
have
to
like
supplicate
the
dhp
server
every
whatever
along
your
leases.
G
J
J
G
J
G
J
J
J
G
D
We're
about
out
of
time
but
but
I
I
think
I
don't
feel
comfortable
doing
an
adoption
call.
I
see
the
conflict
I
see
with
this
draft
is
the
beginning.
You
talk
about
unifying
dhcp
and
neighbor
discovery
sort
of
broad
goal,
but
then
you
also
talk
about
some
very
specific
use
cases
and
I
can't
really
figure
out,
if
which
you're
trying
to
do
here
or
both
and
trying
to
do
a
unification.
I
think,
is
a
broader
issue,
so
I
think
this
request
needs
more
work.
J
J
Okay,
so
what
I
want
you
guys
to
remember
that
I
mean
in
this:
there
are
some
illustrations,
so
anything
with
green
color
is
a
classic
ipv6
node
and
has
anything
with
blue
color.
Is
a
service
six
capable
node
anything
any
node
that
has
an
arrow
on
top
of?
It
is
the
node
that
we
are
focusing
on
at
the
given
time.
J
Now
let
me
talk
about
a
bit
of
history
of
this
draft,
so
this
draft
was
first
submitted
in
july
of
2017,
and
this
was
submitted
to
six-month
working
group
at
that
time.
That
scope
of
the
graph
is,
how
do
we
basically
take
the
classic
ping
and
traceroute
mechanism
that
exists
in
the
36
network
and
make
it
work
within.
J
Network
and
it
got
revision
back
in
october
2017,
but
in
february
or
close
to
december
of
2018,
we
added
also
a
srv6
thing
in
trace
route,
which
is
a
pinion
trace
route
to
a
sit
function,
and
this
is
when
we,
it
becomes
more
of
a
subject
expert
being
in
the
spring
working
group.
So
we
moved
the
draft
to
spring
working
group
there.
We
added
the
srv16
and
traceroute
mechanism,
which
included
a
second
by
segment
and
will
be
second
by
segment
ping
and
we
will
trace.
J
There
was
a
revision
one
in
july,
which
is
offering
residents
working
group
the
most,
and
that
is
the
as
part
of
the
last
call
comments
on
srh
draft.
The
obit
will
have
moved
from
the
srh
draft
to
this
draft.
The
definition
of
and
comment
there
was
that
the
bit
should
be
defined
where
we
do
define
the
processing
of
that
bit
and
then
this
job
will
start
to
also
define
the
processing
of
the
orbit.
J
J
H
J
Ping
in
place,
root
to
a
loopback,
address
or
ipv6
address,
and
then
there
basically
ipv6,
related
processing
remains
unchanged.
Overall.
In
this
document,
it
works
seamlessly
with
the
classic
ipv6
moves
and
but
for
the
srv6
ping
mechanism,
we
define
a
new
message
to
it
him
for
the
icmp.
So
this
is
something
of
the
interest
of
this
working
group.
There
are
a
lot
of
registry
requests
done
so
definitely
like
this
working
group
to
take
a
look
at
that.
D
D
J
Just
for
the
I
don't
have
all
the
illustrations
that
are
there,
but
just
for
registration
so
that
we
can
see
that
this
works
seamlessly
here.
In
this
example,
like
we
have
mode
number
one
that
does
one
depending
ipv6
address:
p4
and
node
number
four,
which
is
green,
which
could
be
a
classic
classic
mode
itself.
And
if
the
sender
wants
that
ping
to
go
via
seed
list
or
via
certain
node,
you
want
to
verify
that
connectivity
or
siblings.
Then
it
can
just
put
in
a
srh.
J
J
Transparently
through
them,
they
will
not
change
and
same
thing
for
the
destination
mode
if
the
restoration,
which
is
shown
as
ipv6,
only
node,
which
is
not
capable
of
processing
srh,
the
processing
does
not
change
they
don't
have
to
so.
This
is
same
as
like
for
locking
extension
header
for
any
other
organization,
so
this
same
thing
applies
with
traceroute
that
that
the
traceroute
can
actually
go
through
an
arbitrarily
sid
list
in
the
network
without
having
to
change
any
processing
at
the
transit
node
or
at
the
destination
mode.
J
Function,
the
graph-
and
we
have
two
flavor
end
to
end
thing
where
you
get
the
restriction
from
the
egress,
sid
or
segment
by
segment
being
where
you
can
get
responsive
from
each
segment.
Along
this
thing,
and
then
you
have
trace
route,
which
is
hopper,
hop,
trace
route.
Where
you
get
information
about
all
the
message
from
all
life:
ipvc,
cable,
node
as
well,
and
then
you
have
overlay
traceroute,
where
you
only
get
responses
from
the
segments
that
are
part
of
the
segment
receiving
suraj
and
no
other
mode
in
the
network.
J
So
for
illustration,
I'll
just
go
over
quickly
on
impressive
function
case,
and
in
this
case
it
requires
the
egress,
the
word
packet
to
be
quantitative,
and
that
is
done
through
insertion
of
an
onion
seed
in
the
packet
by
by
the
node.
They
are
initiating
it
and
that
will
force
the
packet
to
be
pointed
at
the
egress
and
the
eager
to
process
the
package
on
the
response.
H
J
A
new
error
code
is
written
so
that
if
egress
doesn't
have
the
seat,
that
is
target
said,
then
it
can
basically
send
a
message
that
targets
it
is
not
implemented.
Illegals
and
in
terms
of
the
overlay
trace
routes
is
the
difference
between
like
a
hopper,
hop
race,
route
and
overlappers
would
be
something
like
hop
by
hop.
Race
route
will
go
ttl
incrementally
and
then
all
the
nodes,
in
this
case,
the
little
like
the
green
moon
and
the
blue
mode
will
respond.
J
So
you
get
only
responses
from
the
node
that
are
part
of
the
segment
that
are
segmented
same
thing
applies
for
segment
by
segment
ping,
where
you
get
responses
only
from
moves
that
are
part
of
the
segment
that
are
whatever
segment
or
india's
orange,
not
any
other
node.
So
that
would
be
include
like
any
classic
node
and
also
any
blue
node
that
are
shown
in
the
little
circle
because
they
are
not
part
of
segment
to
the
processing
of
the
orbit.
Only
happens
at
the
node,
which
is
part
of
the
segment.
J
A
D
J
J
J
J
I
posted
a
message
on
this
ipv6
mailing
list
and
if
you
have
any
interest
in
this,
we
are
requesting
that
you
please
provide
feedback
on
the
mailing
list.
We
don't
want
to
misinterpret
no
comments
incorrectly
and
basically,
what
we're
doing
here
is
proposing
an
ip
prefix
specification
option.
So
what
this
will
do
is
basically,
if
there
are
ip
some
specification
outside
that
you
would
like
to
do
that.
J
J
C
J
D
G
J
J
N
Q
E
P
E
Towards
the
end
of
myth,
the
multi-interface
is
working
great.
We
were
discussing
pvds
and
such,
and
actually
I
made
a
very
impassioned
argument
by
around
tying
all
the
metadata
information
that
you
wanted
to
on
a
per
prefix
and
was
basically
knocked
down
and
it
was-
and
thus
was-
you
know,
stepped
out
of
the
way,
and
then
it
was
the
pvd
id.
That
is
the
collection
point
for
that
with
the
optimization
that
eric
mentioned.
E
This
work
started
about
a
year
ago
now,
as
a
response
to
the
linear
zone
sent
from
3gpp.
I
have
provided
various
work,
including
pvds
as
a
possible
solution
for
this
problem.
They
were
evaluated
by
3gpp
and
they
replied
with
another
liaison
statement
indicating
that
they
want
the
array
option
so
and
by
the
way.
To
be
honest,
we
think
this
is
the
most
optimized
way
of
doing
that.
So,
yes,
we
are
aware
of
various
other
work
that
has
been
done
in
the
past.
In
itf.
Q
F
E
G
H
E
E
J
I
think
I
might
have
a
better
justification
for
not
using
pvds
for
this,
and
I
I
believe
that
the
justification
for
not
using
pvds
is
that
these
are
actually
in
the
same
pvd.
For
all
intents
and
purposes,
they
really
are.
These
addresses
are
really
on
the
same
network,
same
bcp,
38
policies
and
everything.
This
is
literally
only
about
topology.
J
This
ip
address
is
closer
to
this
anchor
point,
and
its
lifetime
is
different
from
this
other
ip
address
really.
This
is
why
I
stood
up
a
little
bit
earlier
and
said
we
should
just
do
this
with
lifetimes,
but
really
these
two
are
in
the
same
pvd
right
so
in
in
any
sense
that
the
pvd
architecture
says
the
consistent
set
of
configuration
information.
These
are
in
the
same
pvd.
E
E
M
J
J
A
G
J
G
D
D
Please
use
the
for
the
authors
for
presenters.
Please
use
the
time
this
week
to
try
to
resolve
open
issues,
and
hopefully,
by
the
end
of
the
week,
you
can
have
be
ready
to
publish
a
new
draft
that
closes
them
all
and
we
can
move
forward
on
some
of
this
stuff
so
good.
So
thank
you
all.
We
finished
30
seconds
early,
very
good
and
we'll
see
you
all
in
bangkok.
Thank
you.