►
From YouTube: IETF101-6MAN-20180319-1330
Description
6MAN meeting session at IETF101
2018/03/19 1330
https://datatracker.ietf.org/meeting/101/proceedings/
B
C
Welcome
to
six-man
yeah
and,
as
we
said
before,
given
the
shape
of
the
room
you're
much
better
off
to
sit
and
closer
to
the
front,
you
may
need
binoculars
to
see
the
slides,
otherwise,
so
welcome
to
London.
Okay.
This
is
the
note.
Well
I'm
sure
you
all
have
memorized
it
by
now,
and
we
have
Geordi
and
Eric
armed
minute.
Takers
and
Mikkel
is
the
jabber
scribe.
Thank
you
very
much
very
appreciated,
and
so
this
is
the
agenda
which
I
can't.
B
C
So
we
have
the
introduction
we're
doing
now.
The
the
to
working
group
documents
are
being
discussed,
node
requirements,
update
and
the
segment
routing
header
and
then
talk
about
interoperability
testing
regarding
that
two
active
internet
drafts,
the
ICMP
errors,
additional
ICMP
code,
point
errors
and
the
ipv6
router
advertisement
for
the
ipv4
unavailability
flag,
which
I'll
percent
and
then
for
new
documents.
The
first
one
was
something
we
asked
to
be
presented
here.
It
was
also
you
can
see
it's
well
in
the
file
name,
it's
a
v6,
ops
document,
but
it
depending
on
the
direction
it
goes.
C
It
may
make
some
standards
recommendations,
and
so
we
wanted
it
discussed
here
and
then
there's
two
to
document
from
Fernando
on
temporary
interface
identifiers
and
in
an
update
to
the
abyss
document
on
the
privacy,
extensions
and
then
lastly,
proposal
for
a
an
identifier
for
segment
routing
networks.
Any
comments
on
the
agenda.
C
A
Ok,
so,
let's
quickly
go
through
the
document
status.
Since
the
last
meeting
we
published
one
RFC,
that's
83
19
on
the
maximum
retail
lifetimes.
In
our
ace
we
have
one
document
at
T
is
G,
which
is
the
Ayana
options
for
the
end.
The
flags
field,
I
think
that's
on
the
teletrac
in
beginning
of
April.
We
have
one
document
in
working
group
last
call
which
we'll
talk
about
afterwards.
That's
the
node
requirements
based
document,
and
we
have
one
active
working
group
document,
which
is
the
segment
routing
header,
which
is
also
on
the
agenda.
A
So
that
was
the
documents
we
are
currently
working
on.
There
are
a
few
adjacent
working
groups
who
are
working
on
documents
that
we
would
like
you
to
take
a
look
at
it's.
The
Internet
area
has
a
fragmentation,
recommendations
document
that
was
also
presented
in
in
v6
ops
this
morning,
but
I
will
be
in
in
the
area
just
after
this
session.
Agaric.
D
A
That
was
very
kinky
by
the
way
there
is
a
ila
document,
also
in
the
interior.
In
OPSEC,
there
are
the
two
v6
filtering
security
recommendation:
documents,
v6
ops.
There
is
reach
requirements
and
conditional
RAS
and
in
segment
routing
there's.
You
know
multiple
documents,
but
probably
the
most
relevant
ones
are
the
it's
the
network,
programming
one
and
the
v6
use
cases.
E
Service
Krishnan
and
this
one
more
document
in
IP
wave.
They
finished
the
ipv6
over
8
or
11
OCB,
so
I
would
like
to
so
once
they
send
it
to
me.
I'm
gonna
have
to
do
a
like
a
two
week:
class
:
six
men
as
well,
just
to
make
sure
that
things
look.
Ok,
because,
like
one
of
the
things
when
we
did,
the
recharter
was
like
to
see
like
you
know
when
whenever
something
requires
like
review
like
push
it
down
here,
so
I
want
to
just
make
sure
six
men
gets
the
same
document:
okay,
cool,
okay,.
B
F
Hello
welcome
to
sunny
London.
Thank
you,
so
I'm
just
going
to
talk
a
little
bit
about
the
updates.
We've
made
264
34
lists,
I.
Think
at
the
last
IETF
we
I
think
since
the
last
idea.
If
we
went
through
the
working
group
last
call,
it
was
around
that
time.
We
had
a
number
of
comments
and
this
talk
is
just
a
little
bit
about
the
updates
you've
made
as
a
result
of
that
post
working
group
last
call,
and
hopefully
we're
now
ready
to
advance.
F
So
just
a
little
bit
on
the
history,
there
started
off
out
of
observing
that
the
previous
node
requirements
document
was
six
or
seven
years
old,
sort
of
you're
good
to
do
a
refresh
we've
been
through
adoption
through
to
the
point
now,
where
we've
got
a
version.
Seven,
that's
a
result
for
the
working
group.
Last
call
and
we'd
like
to
hopefully
push
this
upwards.
F
So
the
change
is
this
one
slide
here,
just
summarizing
the
changes
we've
made
since
IETF
100
and
that
working
group
last
call
if
you've
got
any
comments
to
make
on
these.
Please
come
up
to
the
microphone
as
I
go
along.
It's
just
this
one
slide
that
we're
summarizing
things
from
so
the
first
one
of
those
is
that
we
synchronize
some
of
the
text
in
64
34
based
to
the
text.
That's
in
eighty
two
hundred
and
some
extent
8201,
which
are
obviously
the
the
latest
or
the
the
new
versions
of
the
v6
core
spec.
F
What
happened
there
was,
as
we
were,
doing,
64
34,
34,
Biss
8200
was
then
being
sort
of
crystallized
into
its
final
state
and
we'd
written
some
words
in
our
bits
before
they'd
become
finalized
in
8200.
So
this
is
just
about
making
those
in
sync
and
I.
Think
it's
largely
in
areas
such
as
overlapping
fragments,
atomic
fragments,
defining
new
extension,
headers
and
handling
path,
MTU
discovery,
so
everything
in
64,
64
34
base
now
matches
up
with
80
280
201.
So
hopefully
that's
okay
with
everyone.
The
next
bit.
F
We
have
some
comments
from
people
interested
in
network
management
about
the
management
section.
It
still
only
says
that
network
management
protocols
may
be
supported
by
nodes
that
hasn't
changed.
What
has
changed
is
that
we've
just
clarified
out
the
things
that
should
then
be
supported
if
you
do
network
management,
so
the
core
yang
modules,
etc,
that
you
would
need
to
support,
and
we
also-
and
it's
in
line
with
the
rooty
requirements
document,
add
addressed
conf
alongside
Netcom.
F
The
next
one
was
a
clarification
on
unknown
upper
layer
protocol
processing.
So
there
was
something
in
8200.
The
was
talking
about
an
unrecognized
next
header
and
it
wasn't
clear
as
to
whether
that
was
an
unknown
ULP
or
an
unknown
extension
header
type.
So
we
just
add
a
little
bit
of
text
to
clarify
that
that
you
should
do
the
same,
regardless
of
which
case
it
actually
is
the
next
bit.
Someone
suggested
adding
this.
This
is
the
update
to
the
multicast
spec
that
basically
takes
some
reserved
bits
and
changes
them
into
flag
bits
that
can
be
used.
F
So
we
said
that
should
be
supported.
I
think
it's
Brian
carpenter
that
made
a
comment
about
type
C
host
behavior.
So
we've
clarified
that
the
type
C
hosts
in
41
91,
those
are
the
ones
that
essentially
maintain
a
routing
table
rather
than
just
having
a
preference
list.
What's
the
next
one,
79
34,
that's
about
the
availability
of
multiple
addresses
per
host.
We
just
had
some
sort
of
Wooley
recommendation
for
that.
We
changed
that
into
an
uppercase
should
again
aligns
with
the
route
requirement
document.
F
We
had
some
additional
text
sent
in
remember
that
I
think
the
episode
checks
that
we've
included
was
still
carried
for
from
the
very
first
node
requirement
document,
which
is
over
10
years
old
now.
So
we
just
had
some
more
modern
text
inserted
there
there's
still
only
a
paragraph,
but
it
was
quite
useful.
F
We
caught
a
reference
to
mo
d
v1
and
replace
that
with
M
or
db2.
No
requirements
is
saying
that
mo
db2
is
a
must
now
to
support
serving
support.
Source-Specific
multicast
next
one
IRC
77072
that
talks
about
how
nodes
may
behave
if
they're
in
a
power
constrained
mode
or
they're
concerned
about
power
consumption.
So
it
says
that
if
you're
concerned
about
that,
then
you
should
support
the
things
that
are
in
this
RFC
previously,
and
you
said
in
May,
which
was
a
little
bit
older
and
then
the
last
thing
was
I.
F
Think
Bob
asked
for
us
to
do
it
in
the
section
where
we
described
the
changes
from
the
64
34
well
and
just
saying
what
we've
changed.
We've
also
added
a
little
bit
to
say
why
it
was
changed
as
well,
which
also
reminds
me.
We
took
out
again
at
Bob's
suggestion.
There
was
a
bunch
of
email
addresses
of
people,
I
think
that
were
acknowledged
from
the
very
first
node
requirements,
and
it's
gotten
in
sort
of
flashback
to
how
things
were
twelve
years
ago.
F
People
I
can
that
Sundra
Fallon
is
in
the
room,
has
all
these
people
and
where
they
were
12
years
ago.
Some
are
still
where
they
were,
but
it's
quite
interesting.
Anybody
deleted
all
that
they've
got
the
names
as
acknowledgments,
but
no
longer
the
interesting
email
addresses
so
I
think
that's
it.
If
everyone's
happy
with
that,
then
I
think
we
can
turn
to
the
chairs
and
ask
whether
we
can
advance
it
I
guess
we
can
have
a
final
check
on
the
list,
but
I
think
we're.
Okay,
any.
A
Any
further
comments
on
that.
Well,
people
are
getting
up
to
the
mic.
Add
add
one
question:
given
this
morning's
discussion
on
the
route
requirements
document,
what
what
would
the
consequences
be
if
we,
if
we
took
that
text
and
a
reference
out
of
of
this
document,
would
that
be
a
possibility
so.
F
F
F
There
are
seven
or
eight
things
that
were
slightly
inconsistent
and
the
author's
discussed
with
Bob
and
I
think
you
were
copied
in
what
we
would
do
in
response
to
that
and
we've
fixed
all
of
them
by
either
updating
What's
in
route
requirements
or
in
6430
for
base
and
I
think
they're
largely
captured
there,
and
the
only
thing
that's
different
is
in
the
route
requirements.
It
says:
Reuters
must
support
the
HP
v6
and
in
here
hosts,
should
support
the
edge
musics,
actually
I'm,
quite
happy
with
that
combination.
F
I
think
that
is
I,
think
that
is
rough
consensus.
Well,
so
remind
me,
so
is
it
still
referenced
in
this
I
think
we've
removed
it,
but
hopefully
Tim
winters
is
looking
right
now
to
come
and
help
me
I
think
we
removed
it
because
it
was
clearly
still
going
to
take
some
time
for
that
to
go
through
and
as
we
heard
this
morning,
it
might
even
not
happen
at
all.
G
G
C
I
Right:
okay,
hello,
everyone
I'm,
just
the
mic
here,
all
right:
Darrin
Dukes
from
Cisco
and
we'll
be
representing
segment
routing,
headers
ITF,
six
band
segments
running
header
version,
tannaz
latest
version
of
that
draft
we've
got
a
fairly
quick
agenda
to
go
through
and
then
open
it
up
to
questions
and
comments
will
be
giving
a
quick
overview
of
some
of
the
highlight
content
of
the
draft.
Although
it's
been
around
for
a
while,
so
I
expect
most
folks
here
have
read
it
or
those
who
are
interested
have
read
it
we'll
go
through
building
the
draft.
I
I
I
Okay,
so
changes
over
the
last
year,
there
haven't
been
many
we've
cleaned
up
the
author
lists,
as
has
been
requested
by
Bob
and
some
other
folks
on
the
list
in
order
to
allow
this
to
progress.
There's
been
some
language
changes
in
reference
to
RFC
8200
and
how
that's
how
it's
referenced
in
the
draft
there's
been
a
response
to
a
technical
issue
on
padding
which
one
of
the
implementers
had
brought
up.
We
had
an
incorrect
value
in
there
that
was
fixed
in
the
draft.
I
E'en
version
is
a
version
9
and
finally,
we
have
running
code
that
implements
this
draft
since
February
2017,
Linux
kernel
4.10
has
a
SR
v6
implementation
Cisco,
since
April
2017
and
onward
we've
come
up
with
two
os's
and
three
a6
that
have
implemented
the
SR
extension
header,
both
adding
it
and
processing
it
at
at
at
each
of
the
end
nodes.
I
Fd
io
has
a
VPP
implementation.
That's
been
available
since
april
of
2017.
You
can.
You
can
grab
that,
and
someone
reminded
me
I'm
going
to
put
after
this
call
put
references
to
these
implementations
on
the
list.
So
folks
can
click
on
them.
Bell
Canada
barefoot
demonstrated
ap,
for
instance,
back
in
May
of
2017
running
SR,
v6
or
SRH
processing.
I
There's
a
this
draft
fefe
spring
s.
Every
six
Interop
goes
into
detail
on
on
what
these
implementations
are
and
what
was
demonstrated.
I'll
send
that
out
the
list
as
well
and
as
the
chairs
I
mentioned,
Rififi
spring
s.
Every
six
network
programming
should
be
looked
at
by
the
folks
in
this
working
group
to
see
what
other
content
is
in
their
IP.
I
Our
disclosures
we've
got
a
single
IP,
our
listing
on
data
tracker
folks
interested
can
look
at
that,
and
that
brings
us
to
the
next
step
which,
over
the
past
year,
there's
been
very
few
updates
to
the
draft.
We
have
some
working
implementations,
and
so
the
question
is
to
the
chairs.
Do
you
think
this
draft
is
ready
for
last
call,
and
can
we
make
that
decision.
A
J
J
The
routing
extension
header
is
just
for
traffic
engineering,
IP
address
to
IP
address,
read
through
network
programming,
and
you
find
that
it's
actually
for
more
than
that
read
through
network
programming.
You
find
some
discontinuity.
Some
some
internal
inconsistency
between
the
two
drafts
you'd
also
find
some
things
that
might
shock
this
working
group
things
like
instances
where
single
packet
carries
two
routing
extension
headers.
For
this
reason,
well,
initially
on
the
list,
I
said
we
should
either
merge
the
drafts
or
last
call
them
both
together.
I
Okay
thanks
there
as
soon
as
to
two
pieces,
if
I
respond
to
that
good,
so
there's
two
pieces
that
work.
Although
specifically
in
that
discussion
on
the
list
section
three
in
Section
4
of
the
routing
extension
header
sources,
the
network
programming
draft
those
sections
are
I,
got
gone
through
them
kind
of
side
by
side
last
night.
J
K
J
I
E
What
the
SIDS
do:
okay,
suresh
krisshnan,
so
the
other
thing
that,
like
you
know,
Ron
talked
about
like
it's
in
the
other
draft
is
the
insertion
stuff
right
and
one
of
the
things
like
we
talked
about
in
six-man
a
while
ago,
was
that
the
author
set
of
this
thing
would
write
another
document
describing
safe
header
insertion.
Okay.
That
document
has
not
been
updated
like
for
a
while
yeah
okay.
So
do
you
have
a
plan
for
updating
the
other
document
explaining
the
safe
area?
Insertion
because,
like
I'll
tell
you
what's
gonna
happen?
E
If
that
doesn't
happen,
and
it's
the
other
drive
from
routing
hits
the
IE,
is
she
I'm
gonna
hold
it
discuss
on
it
indefinitely?
Okay,
so
I
want
this
work
to
be
done
and
I
don't
want
to
see,
realize
the
work
so
I
want
this
work
to
pick
up
right
now,
so
that,
like
before
the
other
draft
hits
the
iesg
I
want
to
see
the
safe
stuff,
so
it
concerned
at
the
speed
like
so
like.
E
So
how
really
like
employ
you
to,
like
you,
know,
put
some
effort
on
that
and
get
that
out
of
the
way
because,
like
otherwise
like
you
know,
people
are
gonna
just
come
up
and
tell
you
all
the
time
that
that
needs
to
get
done
right
now
so
and
I'm
personally,
fine
with,
like
you
know
this
going
to
last
call
wrong.
All
drones
come
in
society
weekend
like
I,
can
push
the
document
here
for
review
right
like
whenever
his
ie
ITF
last
call
I
can
push
it
here
right
and
get
review
on.
E
E
I
M
This
is
of
the
point
I
want
to
raise.
Is
that
wrong
comment
and
there's
a
commenter
on
different
draft,
not
on
this
truck,
and
if
you
take
in
logic
for
the
mpls
data
plane,
labels
were
defined
and
we're
still
using
and
defining
those
usage
of
that
labels
later
and
with
their
spirit
of
working
code
and
in
trop.
If
there's
also
in
the
presentation
that
talks
about
interrupts
that
happen
recently
evolved
along
with
all
these
in
flocks,
I
think
we
are
ready.
This
is
being
stable
for
a
long
time.
M
We
have
enough
working
code
and
we
can
define
other
like
the
different
network
programming
uses
of
this
draft.
In
other
cases
like
l3
VPN,
another
use
cases
separately
and
they
will
be
reviewed.
They
will
be
reviewed
here
as
well
as
spring
and
same
with
Draupadi.
They
would
be
reviewed
here.
Yeah,
that's
really
very,
very
same
page.
J
Following
up
on
the
last
comments,
first
I
think
the
middle
I
think
it
might
be
a
synthesis
of
what
you
just
said.
The
minimum
requirement
for
this
document
is
to
describe
the
entire
SRV
sex
forwarding
plane,
not
necessarily
every
instruction
the
instructions
are
going
to
be
invented
for
years
and
years
to
come,
yeah,
but
enough.
So
you
understand
how
the
forwarding
plane
works.
Mm-Hmm
insertions
part
of
it
there's
some
important
there's
some
heavy
lifting
to
do.
N
This
to
me
for
a
Mojave
I,
one
added
additional
information.
In
fact,
we
also
implemented
our
v6
features,
I
think
as
as
they
are
already
several
I
sorry,
six
implementation
in
the
industry
and
the
into
our
ability
test
either
prepared
and
they
use
being
carried.
Our
so
I
think
this
is
the
adoption,
the
last
car
of
the
draft.
You
will
set
up
a
baseline
user
for
the
utility
at
Hearst
here,
so
we
supported
this.
The
last
core
of
this
draft.
Okay,.
B
E
Serious
Christians
completely
unrelated
thing
when
you
talked
about
tracking
the
implementations
right
so
instead
of
like
putting
it
on
the
list,
there's
an
IRC
that
describes
like
implementation
status
section
for
the
drives.
So
what
you
can
do
is,
like
you
can
add,
that's
things
like
seventy
nine.
Forty
two
is
seven
star
for
two
I
think
in
sending
around
42.
So
you
can
add
the
section
it
says
like:
okay,
there's,
a
Cisco
implementation
dollar.
You
can
put
all
those
things
in
there
and
the
thing
is
published
as
RFC.
E
C
O
P
A
Think,
just
just
one
general
comment
from
from
our
perspective,
you
know
weird
regarding
to
what
Ron
said:
I
think,
the
more
you
know
the
smaller
and
more
core
and
more
baseline
or
the
mechanism
can
be
in
this
document.
With
a
few
of
the
pendants
ease
on,
you
know
that
networking
programming,
I
guess,
is
still
an
individual
draft
right.
The
easier
I
think
this
is
to
serialize
and
progress
quicker.
I
A
I
C
C
A
R
R
So
there
are
cases
where
either
of
them
may
drop
packets
because
of
extension
headers,
because
the
header
is
too
long,
even
though
this
is
might
be
non-conforming,
it
is
kind
of
reality
in
some
situations,
so
the
effects
of
the
drop
source
has
no
idea
why
their
packets
are
being
dropped.
So
this
kind
of
leads
us
to
no
visibility.
We
don't
know
what's
happening
without
the
feedback
can't
fix
the
problem.
R
Middleboxes
it's
in
a
sense,
too
easy
to
drop
packets
without
incurring
any
cost.
So
the
net
result
of
this
is
in
the
case
of
extension,
headers.
It's
just
easier
not
to
use
them,
but
as
we
see
with
segment
routing
and
some
other
proposals,
we
do
want
to
use
extension
header.
So
it's
becomes
more
of
an
immediate
problem
is
following
thing.
R
So
the
proposal
is
some
new
ICP
errors,
and
these
can
be
sent
by
host
and
middleboxes
and
I,
wouldn't
know
what
they
are:
ICMP
errors.
So
all
the
normal
caveats
of
ICMP
errors
being
generated
blocked.
Those
should
apply
as
well.
The
Security's
consideration
should
be
very
similar
to
the
normal
ICMP
airs.
The
idea
is
that
the
source
when
it
gets
such
an
air
at
least,
can
log
it
if
not
take
corrective
action.
R
So
the
proposal
is
modifier
or
introduced
for
parameter
problems
code,
one
is
unrecognized
header
type.
This
actually
exists.
The
idea
here
is
that
intermediate
nodes
could
also
send
this.
So,
for
instance,
if
an
intermediate
node
needs
to
parse
into
transport
layer
to
do
a
firewall,
look
at
ports,
for
instance,
and
if
it
doesn't
recognize
the
headers
to
be
able
to
do
that,
it
could
send
this
if
it
has
to
drop
the
packet.
For
that
reason,
so
this
could
be
distinguishable
from
the
normal
use
case.
R
Where
NAT
host
is
sending
this
message
based
on
the
IP
address
of
the
source
IP
address
of
the
ICMP
air.
If
it
matches
the
destination
of
the
original
packet,
then
it's
a
source
or
the
destination
actually
sending
the
error.
Otherwise
it
would
be
a
middle
box
code.
Point
number
four
is
extension
header
too
big.
So
this
is
a
single
extension
header
which
just
has
an
enormous
size
and
the
device
can't
process
that
extension
header
chain
too
long,
it's
kind
of
similar.
Within
this
case
it
refers
to
the
whole
chain
and
there's
two
possibilities
here.
R
One
is
the
chain
is
too
long
in
terms
of
number
of
extension,
headers
and
the
other
one
is.
The
aggregate
length
of
the
chain
is
too
long,
so
we
allow
for
both
of
those.
It
should
be
fairly
obvious
from
the
pointer
which
one
of
those
two
it
is
and
in
code
point.
Six
is
too
many
options
in
extension
header.
So
this
applies
to
destination,
destination
options
or
hop-by-hop
options.
This
is
when
the
count
of
options
gets
too
big.
R
We
also
define
one
ICMP
destination
unreachable,
so
this
is
for
headers
to
long.
This
is
a
little
more
generic
meaning
the
full
list
of
headers,
not
necessarily
just
IP,
but
other
headers
was
too
long
for
the
node.
So
it
sends
this
air
back.
This
needs
to
be
a
destination
reachable
because
it's
not
a
parameter
problem.
It
does
not
necessarily
apply
to
the
IP
header.
R
So,
given
all
these
errors,
we
can
define
a
reporting
priority.
Priorities
basically
goes
from
existing
ICMP
airs,
unrecognized
next
header
type
too
many
options,
extension
header,
too
big,
and
then
the
header
chain
too
long
for
a
number
of
headers
header
chain,
too
long
for
number
of
bytes
and
then
just
headers
too
long
so
trying
to
go
from
most
specific,
to
least
specific.
So
the
idea
is,
if
multiple
errors
apply
in
the
same
packet.
R
The
note
should
send
the
one
that's
most
gives
the
most
specific
error
message
in
most
cases
we're
using
the
ICMP
error
pointer
to
point
to
kind
of
the
offending
byte
in
the
case
that
the
length
is
too
long
in
terms
of
number
of
bytes,
it
points
to
the
first
byte
after
the
maximum
that
would
have
been
allowed.
If
it's
in
the
case
of
something
options,
where
there's
too
many
options,
it
points
to
the
first
byte
of
the
option
beyond
the
number
of
options
that
would
be
allowed
so
for
parameter
problems.
R
R
So
question
is
always
what
is
the
host
going
to
do
with
this?
So
first
thing
at
least
log
in
so
we
get
this
logging
information.
This
is
an
error
back
to
the
administrator
when
somebody
goes
to
debug
the
problem,
at
least
they
have
this
information,
and
maybe
offline
can
rectify
this
situation
by
not
sending
the
extension
headers,
maybe
the
longer
term.
We
report
this
error
to
the
application,
so
the
application
may
be
able
to
take
action.
R
One
thing
we
foresee
in
some
use
cases
of
extension
headers
is
to
do
something
like
happy
eyeballs
for
extension,
headers,
where
we
try
different
variants
and
when
something
goes
through.
Consider
that
a
success,
but
if
it
doesn't
back
off,
maybe
try
to
use
fewer
extension,
headers
try
to
find
a
right.
Come
so
if
we
have
this
feedback
coming
in,
it
actually
would
expedite
that
process
of
of
narrowing
down
what
the
acceptable
list
of
extension
headers,
for
instance,
are.
R
I
Darrin
Duke
Cisco
Systems
Tim,
the
when
you
say
you
point
to
the
extension
header
the
bite
to
past
the
the
thing
that
would
be
offending
or
that
was
too
long.
How
does
that
work?
For
you
know
if
I
want
to
be
the
generating
this
air
out
of
an
ASIC,
for
example,
and
I
only
get
to
look
at
the
first
two
hundred
and
some
bytes
or
whatever
this
packet?
How
do
I?
How
do
I
point
to
the
next
thing
that
I
couldn't
get
to
to
to
know
where
that
next
thing
is
we're
an
encapsulation?
I
R
R
E
R
C
Well,
so
let
me
just
first
make
a
comment,
so
I
guess
I'm
somewhat
skeptical
that
hosts
are
going
to
be
able
to
make
any
real
use
of
this.
You
know
I,
you
know
it's,
like
extension,
headers
get
added,
you
know
they
may
get
added
in
the
application
they
may
get
added
down
further
in
the
IP
stack,
so
I'm,
not
I'm
having
you
didn't,
haven't
convinced
me
that
their
hosts
are
going
to
be
able
to
take
make
any
use
of
these
extra
coat
points.
R
So
consider
hostess
send
a
setting
a
destination
option
and
that
would
come
probably
from
the
applications
application
setting
destination.
Often
this
is
what
we
intend
to
do
in
fast,
for
instance,
where
we're
attaching
service
tickets.
So
probably
we
have
with
extension.
Headers
is
they're,
not
reliable
right,
so
so
we
know
that
they're
dropped,
often
in
the
Internet,
so
anything
we
can
do
to
facilitate
their
use
would
be
good.
R
So
we
are
going
to
be
in
situations
where
I
want
to
use
extension,
headers
on
the
intranet
and
I'm
gonna
try
to
use
them
and
if
they
don't
work,
I'm
going
to
have
to
back
off
I
can't
just
say
the
application
dies.
So
we
have
to
have
that
that's
sort
of
back
off.
So
really
it's
a
question:
how
do
you
implement
a
back
off
when
extension
headers
fail
on
a
path
right.
R
The
feedback
is
one
one
part
of
that,
so,
regardless
of
the
feedback,
the
problem
doesn't
go
away.
Right,
I
still
want
to
use
extension,
headers
and
obviously,
since
this
is
ICMP,
that's
unreliable
in
itself,
so
we're
not
always
going
to
get
the
feedback.
But
what
I'm
hoping
is.
This
could
be
a
way
to
expedite
that
that
loop
to
shorten
the
the
length
of
time,
otherwise
I
have
to
do
a
whole
bunch
of
probing
and
things
like
that
to
try
to
find
the
magical
extension
header.
R
So,
for
instance,
if
it
really
is
a
case
where
device
is
dropping
it,
because
it's
too
long
versus
if
it
was
shorter,
they
would
have
allowed
the
extension
header.
How
do
I
quickly
get
to
that
that
point
because
of
setting
say
three
extension
headers,
maybe
one
of
them
I
really
need
what,
if
I
didn't
need
the
other
two,
so
I
guess
what
I'm
looking
for
here
is
some
flexibility
and
being
able
to
use
extension,
headers,
I
think.
C
R
My
feeling
is,
we
haven't
deployed
extension
headers
to
the
extent
we
really
know
how
how
they're
gonna
work
in
mess
and
anything
we
can
do
to
to
assist
that
I
think
would
help.
So
maybe
host
won't
have
a
problem
with
this,
but
as
as
we
pointed
out,
we
already
have
limitations
on
host
to
do
know,
handle
denial
of
service
attacks.
So
if
you
remember
that
that
discussion,
without
that
extension,
Harriers,
would
be
a
pretty
big
pain.
A
So,
just
a
little
standing
there
just
to
follow
up
on
what
Bob
said,
I
mean:
do
we
have
with
existing
host
implementations?
Do
we
have
any
good
knowledge
about
what
they
do
with
the
existing?
I
simpiy
errors,
I'm
kind
of
asking
about
the
granularity
you
need
I
mean.
Would
it
suffice
if
you
just
got
parameter
problem,
for
example,
I
mean
if
hosts
don't
do
anything
with
them
anyway,
today,
I,
don't
know
well.
R
I
mean
that
they
process
some
random
package
of
BIG's,
definitely
processed
as
for
parameter
problems,
the
most
likely
thing
as
they
would
log
it,
and
a
primitive
problem
today
would
more
likely
and
indicate
an
actual
error
as
opposed
to
to
a
limit.
So
there
is
a
little
bit
difference
there.
What
I
think
we
would
need
is.
A
R
S
S
It's
not
being
prohibited
by
policy
directly.
Do
we
have
a
header
not
allowed
error
like
a
port
unreachable?
Is
there
it
like
if
I
want
to
filter,
shim
six
extension,
headers
I
don't
want
to
allow
any
of
those
packets?
Is
there
a
way
to
tell
the
hosts?
No,
no,
you
don't
get
to
send
shim
six
extension.
Headers
included.
The
network
does
not
filter
packets
in
six
month.
S
O
E
Standard
solution
so
like
so
just
like
you
know
like
no
paraphrasing
learns
or
channeling
him
right,
so
the
site
that
didn't
understand
it
didn't
understand
it.
So
it
doesn't
know
it's
a
shim
6.
So
it
says
like
this
like
location
in
the
packet
where
I
saw
the
zoom
6
header
I,
didn't
know
what
it
was
so
I
changed.
The
subject.
S
I
said
so:
I'm
not
talking
about
unknown
I'm
talking
about
if
I
have
a
firewall
that
doesn't
love,
shim,
6
extension
header
packets.
Can
it
signal
to
the
sender
to
say
this
specific
extension
header
I
I'm,
not
gonna,
allow
like
I
can
tell
it.
I
filtered
this
because
of
the
destination
TCP
port.
That's
why,
like
that's,
why
I
dropped
it,
but
do
we
actually
have
a
way
to
signal
this
for
headers?
Do
we
need
it,
there's
a
policy
problem.
S
T
Mike
Ackerman
a
different
perspective,
perhaps
I'm
from
one
of
those
horrible
enterprises
that's
resistant
to
d6
deployment.
One
of
our
excuses
is
the
lack
of
network
management,
information
and
error
information.
I
think
this
would
go
a
long
way,
so
I
think
this
is
good
work
and
we'd
like
to
endorse
it.
T
J
Ron
Bonica
Juniper
Networks
only
has
a
good
point.
That's
sending
a
parameter
problem
message
to
a
host
may
not
be
enlightening.
I
go
to
a
website,
it
doesn't
work.
I'm,
not
gonna,
go
look
at
ICMP,
I'm
gonna
go
to
a
different
website,
but
this
might
be
helpful
when
the
source
is
a
tunnel
ingress
node.
Then,
if
it,
you
know,
if
everything
going
through
a
tunnel
black
holes,
somebody
might
look
at
a
log
to
figure
out
who
it
was.
That
was
complaining
about
not
being
able
to
pass
extension
headers.
B
A
U
A
A
C
C
Yes,
so
this
came
about
based
on
a
discussion
we
had
at
the
last
ITF
on
the
you
know
the
ipv6
only
network.
We
noticed
that
dual
stack
hosts,
which
I
think
are
most
toast
these
days,
we're
creating
we're
still
trying
to
use
ipv4
they're
getting
addresses
they're
attempting
to
reach
services.
You
know
and
it
wasn't
a
giant
amount
of
traffic,
but
it
was
some
traffic,
and
so
there
was
sort
of
this
discussion
on
the
v6
list
about
this,
and
so
I
ended
up
with
Brian
carpenter.
C
So
yeah,
and
so
the
you
know,
behaviors,
we
noticed
where
you
know.
We
see
a
lot
of
layer,
two
broadcast
traffic
before,
of
course,
just
uses
broadcast.
You
know
you
see
ARP,
so
it
wakes
up
every
every
note
on
the
on
the
land
on
the
link
will
receive
this
stuff.
This
causes
you
know
drain
in
in
battery
life,
for
you
know,
devices
that
aren't
plugged
in
and
then
possibly
could
you
know
if
you
were
intending
to
run
v6
only
it
could
possibly
allow
ipv4
as
a
back
channel
for
things.
Administrator
may
not
be
looking
at.
C
C
So
you
know
there
are
two
values
and
the
draft
would
update
the
IANA
registry,
appropriate
I
in
a
registry
to
define
this
flag
so
that
there
are
other
router
configurations.
You
know
that
it's
this
is,
they
should
be
done
on
a
default
router.
There
are
other
kinds
of
router
like
devices
that
you
know
don't
route
traffic,
but
it's
the
one
to
send
advertisement.
So
we
so
host
will
only
process
this
if
it's
a
default
router
and
the
notion
is
that
the
administrator
sets
a
swag.
C
C
C
If
all
RA
is
received,
have
the
flags
at
the
one,
then
the
host
should
not
attempt
ipv4
operations.
You
know
it's
reasonable
to
assume
there's
no
ipv4
on
the
link,
and
you
know
counter
to
that.
If
you
receive
any
flags
with
zero,
you
continue
with
before,
and
this
avoids
a
lot
of
problems
that
you
know
to
you.
It's
hard
to
use
it
maliciously,
because
the
other
routers
will
still
be
advertising
with
zero.
If
there
was
before
you
know
it's
advisory,
we
can't
the
host
really
would
get
to
decide
what
they
want
to
do.
C
You
know
other
choice.
The
host
may
decide
to
delay
before
operations
until
they've
they've
received
our
A's,
or
they
may
only
want
to
do
before
if
they
actually
have
an
application
that
requests
it
so
I
mean
this
is
the
time
for
discussion,
but
you
know
the
authors
are
basically
asking.
Is
the
working
group
interested
in
adopting
this
so
questions.
C
S
Draft-
it's
not
in
the
previous
right,
because
if,
if
let's
say
that
the
upstream
is
a
pppoe
session
and
it
is
li6
only
the
router
discovers
this-
is
it
okay
for
the
to
set
it?
If
that
condition
is,
is
that
administrative,
or
is
that
not
allowed
by
this
document?
Ask
that
again?
Okay,
so
the
the
the
router
has
no
v4
connectivity
upstream
right,
and
so
it
doesn't
configure
itself
any
v4.
S
Is
it
okay
to
set
this
flag
then,
because
it's
not
administered
to
set
by
person,
it's
discovered
that
this
is
the
condition
it's
in
get
home
gateway,
pppoe
session
v6
only
on
on
on
the
PPP,
oh,
he
said
so
I
think
so,
but
I'm
not
sure.
V
I
have
two
questions,
one
which
I'm
not
asking
and
one
which
I'm
going
to
ask.
So
the
question
I'm
not
asking
is:
why
doesn't
that
happen
over
DHCP
v4,
but
I'm?
Not
asking
this
question
and
the
question
I'm
asking
is:
why
is
it
a
flag
rather
than
an
option,
and
the
reason
for
that
is
that
I
can
see
three
values
for
that
one
is
this
Rooter
makes
no
claims
about
whether
there
is
any
DHCP
v4,
because
I'm,
an
ipv6,
router
and
I
know
nothing
about
ipv4.
V
C
C
W
C
V
Envisioning,
a
future
in
which
by
default
networks,
have
no
ipv4,
and
in
this
future
it
would
be
weird
to
remain
forever
with
a
flag
set
to
one
saying:
don't
use
NetBIOS
compared
us
to
current
situation.
Suppose
there
is
in
every
single
route
or
advertisement
packet,
a
bit
that
is
set
to
one
to
say:
do
not
speak
this
protocol
that
has
been
obsolete
for
20
years.
How
are
we
going
to
explain
to
our
grandchildren?
What
is
this
one
doing
in
the
route
or
advertisements?
Well,.
V
C
To
and
and
I
I
gave
him
I
gave
two
answers.
One
was
you
know
it's
good
to
remember
our
history.
So
if
this
is
the
only
remnant
of
before,
then
that's
not
so
bad,
but
the
other
thing
too
is
I,
mean
20
years
from
now,
when
people
have
forgotten
what
v4
is,
we
can
probably
reclaim
the
flag
and
use
it
for
something
else.
C
C
W
Lorenza
could
be
I
think
so.
I
sympathize
with
the
problem
and
I
think
we
need
to
solve
it,
but
every
solution
has
been
here
that
has
been
proposed
so
far
has
been
suffering
like
the
death
of
a
thousand
cuts
and
I.
Think
what,
if
there's
a
what,
if
there's
three
Reuters
that
don't
agree
like
what
happens
on
this
case?
What
happens
in
that
case?
W
V
W
Also
specifies
what
to
do,
and
therein
lies
the
potential
for
disagreement
and
thus
endless
endless
lack
of
progress.
So
what
I
could
suggest
is
we
could
cop
out
entirely
and
say
we
don't
know
what
to
do,
but
there's
a
hint
that
there's
there's
no
before
and
what
I
can
do
is
like.
I
can
change
my
exponential
back-off
timer
from
cap
to
two
minutes
to
cap
to
two
hours
and
I
saved
a
lot
of
power
like
that.
W
You
know
he
can
do
something
different
and
you
know
whatever
they
can
do
something
different
and
I
think
you
know
at
least
we
can
publish
something
so,
like
I
said
generally,
we
talk
about
adopting
working
on
a
problem
as
opposed
to
working
on
a
specific
incarnation
of
a
draft
resolution.
I
think
this
problem
is
is
important,
useful
to
solve,
and
if
we
can't
like
stop
disagreeing
on
it,
let's
just
cut
out
and
say
look:
this
is
just
a
hint
do
whatever
you
want
with
it,
I
mean.
C
C
W
E
Video
right,
suresh
krisshnan,
so
like
one
thing,
I
don't
want
to
happen
here
is
like
sunset
for
over
again,
so
I
think
it's
an
interesting
problem
to
solve,
but
I'm
not
sure
if
it
should
be
solved
here.
So
that's
like
really
my
comment
and
so
I'll.
Let
other
people
talk
and
then
I'll
get
back
in
line
after.
X
Pete
Steven
Smith,
apiece
and,
and
we
dhcp
a
little
bit
of
RFC
1918
space,
so
you
can
get
to
the
file
server
and
everything
else
comes
from
v6,
where
you
see
Rita
over
a
written
ounce
meant,
if
you
send
me
a
zero
in
that
bit,
you
are
asserting
that
my
file
server
will
give
you
global
v4
connectivity
through
your
RFC
1918
space,
which
is
not
true.
If
you
write
one
in
that
bed,
you
are
telling
me
I
should
not
make
any
v4
connections
and
disconnect
my
file
server,
which
is
very
unhelpful.
X
C
X
C
L
L
That's
what
I
that
what
so
he
said,
I
thought
pizza
certian
was
that
the
flag
being
said
means
there
is
no
ipv4
on
this
network
and
I
great,
but
but
I
thought
that
what
Bob
said?
No,
that's
not
what
Pete
said.
That's
okay,
that
right,
but
the
plates,
not
what
the
draft
says.
What
the
draft
says
is
this
router
that
is
issuing
this
this.
This
packet
is
not
a
default
gateway
for
ipv4,
which
means
there
may
be
others
in
the
network,
such
as
your
ipv4
default
gateway,
I.
Think
most.
L
Then
you
would
not
set
this
bit
because
the
same
router
is
providing
both
v4
and
v6.
There's
just
easy:
P,
okay,
the
local
thank
you
for
the
local
network.
Okay,
I
misunderstood
that,
so
so
just
so
there's,
but
there's
no!
But
it's
also
that
router
is
there
for
another
default
gateway,
so
the
host.
So
if
it
gets
DHCP
before
that,
maybe
a
disambiguation,
then
it.
Y
S
L
It's
a
so-so.
We
may
need
to
refine
the
language
to
say
that
that
if
you
see
you
see
other
hints
implying
that
there
is
ipv4
such
as
you
have
also
sent
a
DHCP
v4
request
and
receives
a
response.
Maybe
that's
an
alternate
hint,
but
it's
also
in
your
case.
I
still
say
you
probably
wouldn't
want
to
set
this
because
because,
if
you're
not
sure
the
host
behavior
is
and
since
it
is
administratively
set
it's
set
by
the
administrator,
yes,
then
it's
of
course
your
choice,
because
it's
your
network
yeah,
usually
it's.
L
That
I
understand
I
think
that
there's
useful
clarification
to
be
made
there.
Oh
I'm
sure
the
document
could
be
printed
so
I
did
want
to
say
that
I
do
think
that
this
solves
problems
that
that
I
have
because
I'm
struggling
to
when
doing
v6
only
testing
I'm
struggling
to
get
v4,
not
there
anymore
I
did
one
actually
I.
Think
Suresh
already
addressed
another
point
that
what,
let's
make
sure
that
you
know
I
think
sunset
4
is
still
technically
open.
This
much.
L
Automatic
or
you
know,
there's
all
of
I
P
before
has
been
manually
turned
off.
That
I
might
not
also
need
to
manually
set
the
bit.
That's
so
that's
a
UI
problem,
even
if
that
all
that
logic
doesn't
exist,
I
am
probably
still
going
to
script
things
so
that
it's
done
automatically
anyway,
because
you
know
I
want
the
the
dynamism
there
so,
but
I
guess
that's
the
same
thing
as
being
manually
set.
It's
just
automatically.
That's
your
way
of
doing
that.
Z
Y
J
link
over
so
I
think
it's
a
good
problem
to
solve
right.
What
I
was
a
bit
confused
when
I
was
reading
the
document
we
given
some
ideas
to
the
host
implementers.
What
to
do
right,
we're
not
prescribing
any
behavior
okay
network
might
give
you
hints.
Let
us
know
before
and
you're
saying
host
might
choose
not
to
start
before.
State
doesn't
include
it
would
not
configure
a
link-local
v4
addresses
or
just
not
trying
to
do
the
HCP.
It
might
be
the
list
of
the
ideas.
Y
Y
H
Webber
Stark
I
think
the
draft
is
useful.
I
think
the
bit
is
useful.
I
think
it
does
no
harm
and
I
think
it
may
do
good,
and
in
that
context
it
may
be
useful.
AA
David's
Ganassi
Apple
I'm,
actually
gonna
work
not
necessarily
disagree
with
the
people
for
me,
but
ask
for
a
clarification.
What
problem
are
you
trying
to
solve
I'm
kind
of
failing
to
understand
the
theory?
What
can
you
give
me
an
example
of
a
network
where
you
would
do
this
like
my
home
and
enterprise?
Well,
this
one
so
the
IETF.
J
AA
C
AA
AA
So
let's
say
that
theoretically,
I
make
client
devices
and
I've
heard
of
that
and
yeah
I
will
have
them
on
my
home
network.
The
home
network
is
configured
this
way.
I
also
have
a
very
old
printer
from
a
different
manufacturer.
That's
before
only
I
still
want
to
talk
to
that
device.
So
even
if
you
set
this
bit
as
a
client
device,
implementer
I'm
still
going
to
do
before
the
glocal
I'm
still
going
to
do
mdns.
Moreover,
link-local
and
I
don't
feel
like
those
problems
aren't
solved
anymore.
Then
you.
AA
AB
Verónica
McKillop,
Microsoft,
IT
I'm
actually
see
the
point,
and
for
me
this
would
be
a
welcome
solution,
so
I'm
in
a
process
of
turning
our
corporate
network
to
ipv6.
Only
that's
for
220,000
users
over
1.5
million
devices,
and
we
have
got
a
problem
that
not
all
the
operating
systems
on
the
network
I
going,
are
reacting
the
right
way.
So,
yes,
there
are
the
self
configured
ipv4
addresses
and
there
are
services
that
are
trying
to
do
work
over
before,
even
though
I'm
giving
them
only
be
six.
Y
General
another
use
case
again:
you
have,
for
example,
enterprise
network
art,
which
is
moving
to
v6
only
and
we
do
not
want
to
care
about
before
anymore.
It
also
potentially
protects
me
from
accidentially
someone
turned
in
DHCP
v4
server
on
the
network,
because,
if
all
my
hosts,
mostly
by
default,
ignore
before
right
and
I
can
tell
them
that
I
I
hate
having
all
these
complicated
features
on
the
switches
right,
it's
I
wanna.
This
is
an
additional
thing
right.
Protecting
me
with
one
one
configuration
on
the
router
and
say
all
this
additional
stuff
on
switches.
Y
E
Wanted
to
ask
you
something
as
well
so
rushed
at
you.
I
already
said
what
I
wanted
to
say,
like
I
think
sunset
4
might
be
a
better
venue
for
this
and
I'm
open
to
this
I
like
doing
this
year,
but
I
think
they
might
have
a
history
of
like
you
know.
What
are
the
things
that
kind
of
came
up
before,
or
maybe
like
I
think
like
are
the
same
culprits
are
involved
in
all
of
these
things,
but
I
think
that
might
be
a
useful
thing.
E
I
can
just
talk
to
Terry
a
little
bit
and
see
like
you
know
how
we
want
to
do
this
I'm
personally,
like
supportive
of
this
work
going
forward
right,
like
I,
just
have
like
no
direct
question
on
where
I
do
think
like
sunset
for
might
be
a
better
venue,
but
there's
not
many
people
left
there
so,
like
that's
that,
that's
like
something
we
had
to
weigh
somewhere,
but
personally
go
ahead.
Do
the
call
and
we'll
figure
out
like
what
to
do
after?
Oh,
we.
E
If
you
have
a
movie
move
like
we
moved
like
I
think
we
from
like
shouting
area
like
envy
or
three
to
interior,
so
like
we
can
do
this
thing
after,
like
we
can
figure
it
out,
but
like
yeah,
that
is
personal.
My
personal
view,
like
would
be
like
that,
would
be
a
better
venue,
but
if
there's
nobody
review
shot
there,
then
we
will
do
it
here
right,
like
that's
my
goal,
to
have
the
right
set
of
people.
Do
everything
I'm.
E
C
A
But
I
think
his
point
is
that
you
have
a
v4
only
linked
there's,
no
correlation,
that
a
host
makes
between
a
v4
and
v6
router.
Suddenly,
someone
just
puts
a
v6
root
on
that
link.
There's
the
only
one
and
it's
going
to
set
that
bit,
and
that
means
that
all
the
notes
that
are
there
already
will
disable
before
right,
because
there's
nothing
else
to
tell
you
the
zero
B
foreign.
N
E
P
G
K
M
Y
Jenny
I
just
realize
it's
a
perfect
example
of
the
situation
when
people
should
consider
deploy
ipv6,
because
if
they
still
sync,
it's
not
there.
It's
actually
there
on
the
network
and
they
still
need
kind
of
ipv6
security,
even
in
the
network
which,
as
they
believe,
is
before
all
right.
So
it's
actually
actually
good
thing
that
you
might
turn
completely
reformed
uniformly
network
using
ipv6,
which
you
believe
doesn't
exist
because.
C
AE
A
A
A
A
B
AF
You,
okay,
this
is
the
same
theme
presentation
we
have
done
this
morning
or
so
to
do
six
up.
Yes,
we
want
to
present
this
methodology
to
ipv6
folks
in
order
to
allow
the
application
of
this
methodology
also
a
BB
six
context,
so
the
erequest
8321
has
been
published
during
the
january.
So
this
is
just
like
to
recap
the
main
points
of
this
methodology.
AF
The
alternate
marking
method
is
based
on
the
marking
batches,
so
every
marking
interval
the
packet
mark
can
be
changed
between
two
values,
red
and
blue,
red
and
blue
means
that
we
can
flips
one
bit
or
we
can
change
between
a
label
label
value
when
the
red
packet
counters
are
running,
the
blue
counters
are
still
and
vice-versa.
So
in
this
way
we
can
take
the
packing
counters
for
each
batches
and
by
comparing
the
counters
of
the
same
batch
between
several
endpoints,
we
can
calculate
in
a
very
simple
way
to
packet
loss.
AF
Also,
the
delay
and
delay
variation
can
be
measured
with
these
methods.
What
are
the
main
strains?
The
main
strengths
of
this
meter
that
that
it
works
on
real
production
traffic,
so
there
is
no
injection
of
syntactic
traffic.
It
works
also
in
case
of
out
of
sequence.
So
if
you
have
reordering
at
the
edge
of
a
batch,
you
can
overcome
this
problem
because
you
can
take
the
counter
in
the
follow
in
the
middle
of
the
following
interval.
So
you
you
don't
have
any
out
of
order
issue.
AF
This
method
works
in
case
of
also
are
not
synchronized
at
networks,
because
the
marking
boundary
is
an
auto
synchronization
signal
all
at
the
network.
So
you
don't
need
a
strict
synchronization
synchronization
between
the
endpoints
and
it
works
without
one
packet.
So
in
packets,
don't
work
in
case
about
order
and
in
case
of
packet
row,
so
in
case
you
have
your
own
pockets
get
lost.
You
cannot
make
the
measure,
but
instead
the
marking
boundary
is
still
valid,
also
in
case
of
packet
rows
and
real
trick.
AF
So
this
is
just
a
quick
view
of
the
application
of
the
main
application
within
ITF.
So
we
have
some
proposal
in
beer
working
group
in
SF
Essene
and
in
NGO
tree
were
you
and
you
can
see
the
other
where
we
reserved
two
beads
for
the
application,
so
RFS
8321
can
be,
can
be
applied
if
we
have
one
beats
or
also
two
beats.
So
there
are
several
alternatives
for
the
application
of
the
methodology.
AF
AF
Regarding
the
delay,
as
I
mentioned
before,
there
are
two
variations,
so
we
can
use
the
single
mark
meter
where
we
have
just
one
flag,
elf,
flag,
that
can
be
used
and
for
the
delay
we
can
consider
the
first
or
last
packet
of
our
patch.
That
is
the
time
reference
for
our
delay
calculation,
but
this
this
method
is
sensitive
to
packet,
roads
and
rocketry
all
day.
There
is
an
another
variation
that
is
a
little
bit
more
complex
that
is
based
on
calculation
of
the
average
time
stamp.
AF
So
each
end
points
can
calculate
the
average
time
stamp
for
each
batch
and
by
comparing
the
two
average
times
time
between
two
end
points,
you
can
calculate
the
average
delay
that
is
the
meaning
like
and
the
same
things
can
be
applicable
for
delay.
Variation
double
mark
is
more
flexible
because
you
can
use
one
flag
for
packet
rows
and
the
other
flag.
D
flag
allows
to
select
some
special
pockets
and
a
set
of
market
packets
that
are
fully
identify
over
the
network
and
by
comparing
the
time
stamp
of
this
packets
along
your
network.
AF
AF
So
what
about
ipv6?
After
after
this
short
recap?
We
know
that
each
layer
is
responsible
for
its
own
I.
Am
so
we
have
some
as
a
Telecom
Italia,
so
as
a
service
provider,
we
have
made
an
implementation
of
this
method
for
ipv4
in
a
p4.
There
is
no
space
to
reserve
some
bits
for
to
apply
this
methodology.
We
use
the
SCP,
but
we
cannot
standardize
it,
but
we
will
try
to
to
do
that
with
ipv6.
So
there
are
some
alternatives
that
we
can
analyze.
AF
For
example,
we
can
apply
the
methodology
to
an
extension
adder
using
an
existing
one
or
anyone
encode
the
market
methodology
into
the
ipv6
address
or
using
two
bit
from
the
flow
level
field.
So
each
of
these
alternatives
have
some
issues,
because
if
we
use
the
extension
adder,
this
seems
less
backward-compatible,
so
so
we
can.
A
proposal
can
be
to
use
an
existing
extension
adder
instead
of
define
anyone.
Otherwise
we
can
use
the
destination
address
to
encode
this,
but
also
this
is
a
little
bit
expensive
and
the
other
alternatives
is
to
use
the
flow
level
field.
AF
A
AF
AF
A
AF
To
investigate
all
the
alternatives,
but
we
we
don't
investigate
so
much,
there
p
v6
address.
We
have
some
ideas,
but
we
didn't
have
implement
and
we
didn't
experiment.
This
I
know
that
there
will
be
some
problem,
but
we
we
got
some
review
and
feedbacks
on
mailing
list.
So
there
is
some
discussion
about
the
flow
label
application,
because
if
we
use
one
or
two
bits
for
marking,
we
we
have
to
just
only
eighteen
or
nineteen
bits
dedicated
for
the
load.
Balancing
so
should
is
enough
to
apply
the
load
balancing.
AF
Otherwise
we
can
use
it's
better
to
use
an
up
by
up
extension
or
a
destination
option
extension.
Another
question
could
be
it's
better
to
use
an
existing
extension
rather
or
defining
anyone.
Otherwise
we
have
also
some
proposal
to
in
mvo
tree
working
group,
as
you
can
see
in
the
second
slide
I
presented
before
so
maybe
I
possible.
Another
possibility
can
be
to
use
an
extensible
except
encapsulation
from
the
other
layer
and
then
also
the
scope
of
the
draft
that
I
can
be.
AF
The
RFS
is
experimental,
of
course,
but
now
we
should
understand
if
this
draft
can
be
informational
or
standard
depend.
Okay,
so
as
a
next
step,
we
would
find
a
great
way
to
apply
this
alternate
marking
method
for
ipv6,
so
not
for
AP.
Before
that,
it's
a
self-made
I
know
made
implementation
because
we
use
the
SCP
field.
That
is
not
allowed
for
this
for
this
function
and
we
want
to
adults.
A
multi
point
alternate
marking
use
case
that
extend
this
methodology.
It
is
a
generalization
for
multi-point
to
multi-point
parts
and
up.
Please
comments,
question
and.
W
Do
wonder
so
that
that
you
we've
got
these
bits
in
the
flow
level
and
nobody
seems
to
know
what
we
should
use
them
for
I,
wonder
if
we
should
and
and
on
the
other
hand
like
the
request,
oh
boy,
it
always
comes
up
and
again
and
again:
oh,
we
need
to
be
able
to
insert
bits
into
the
header.
We
need
to
be
able
to
impose
extension,
headers
and
so
on
you
can
we
get
like.
W
E
I'm
suresh
krisshnan,
heidi
hat
off
again,
like
so
I
wrote
this
draft
to
try
to
do
that,
and
we
didn't
get
consensus
like
so
five
years
ago
possible
but
like
it
was
like
pretty
much
like
very
polarizing
topic
and
I.
Think
the
the
the
main
issue
is
like
if
somebody
is
using
this
for
some
kind
of
hash
based
load
balancing
it.
E
W
So,
no,
but
think
about
it.
This
way,
like
the
flow
label
stuff.
What
is
the
flow
label
stuff
except
you?
What
is
it
but
not
essentially
like
imposing
random
values
on
to
the
floor
level?
So
so
I
guess
yeah
and
so
how's
it
different
really.
How
is
it
different
from
putting
random
stuff
in
the
flow
level
in
transit.
F
John,
isn't
you
say
this
came
up
five
years
ago
and
got
thrown
out?
Isn't
it
since
then
that
we
updated
the
flow
table
spec
to
say
you
can
write
right
all
those
bits
to
be
some
random
value
if
it's
arriving
set
a
zero,
but
not
if
it's
already
set
to
some
random
value.
So
no,
but
the
problem
is
in
your
case,
most
operating
systems,
but
I,
don't
know
I,
guess
most
of
them
probably
set
it
right.
W
Think
you
should
look
into
putting
them
in
any
in
a
TCP
check
sum
and
because,
by
definition,
all
these
proposals
basically
like
well
will
invert.
We
will
invert
this
transformation
when
it
exits.
Our
domain
use
the
checks
on,
because
that's
like
entirely
entirely
reversible
right.
It
should
be
calculated
in
the
TCP
packet
yeah.
W
W
W
AF
AE
A
Okay,
I
think
I
think
we
have
to
continue
this
on
the
list
and
but
at
least
for
now
it's
an
experiment
right,
so
we
can
yes,
okay,
thank
you
and
I
think
Fernando.
You
are
remotely
at
least
you
were
the
last
time.
You
said
something.
Can
you
please
lower
the
gain
on
your
microphone
or
speak
lower
or
say
a
little
bit
further
away
from
it,
because
you,
your
sounds.
AG
K
So
this
is
a
document
that
we
presented
at
the
last
ITF
meeting
its
recommendation
on
temporary
ipv6
interface
identifiers
next
slide.
So
what
are
the
goals
of
this
document?
Well,
essentially,
it
is
like
RFC
1864,
but
for
temporary
addresses.
So
essentially,
what
we
do
is
we
specify
requirements
for
generating
temporary
addresses.
K
We
also
clarified
that
notes
are
not
required
to
generate
stable
addresses
and
that's
it
again.
This
is
the
same
as
RFC
1864,
but
for
temporary
addresses.
As
a
comment
in
in
a
previous
version
of
this
document,
the
document
was
proposing
or
recommending
two
possible
algorithms
to
generate
these
addresses.
This
has
been
removed
and
moved
out
into
a
different
document.
So
next
slide.
K
These
are
the
requirements
that
we
have
so
far.
First,
that
he
you
know,
these
IDs
must
have
a
limited
lifetime
that
the
lifetime
needs
to
be
reduced
by
security,
meaningful
events
that
the
IDS
needs
to
be
different
for
different
prefixes.
This
is
something
that
is
different
from
what
was
the
case
in
RAC
49.1
that
they
should
not
embed
layer.
2
addresses,
obviously
that
they
must
be
difficult
to
predict
by
an
outside
entity
and
that
they
must
be
semantically.
A
big
next
slide.
I.
K
Yeah
that
you
know
the
last
field
of
the
requirements
is
it
shouldn't
be.
The
layer
2
address
must
be
obviously
difficult
to
predict
by
an
outside
entity
and
must
be
semantically
opaque
next
slide.
Okay
and.
A
A
A
Okay,
so
any
comments
on
this
draft
and
these
requirements
now,
otherwise
we
you
get
a
chance
again
after
the
next
draft
as
well.
Okay,
let's
go
to
the
next
one,
so.
K
Essentially,
this
is
49-41
this
document
we
started
some
work
on
this
document,
based
on
the
suggestion
that
we
received
during
the
last
six
month
meeting.
So
originally
we
were
doing
everything
in
the
biggest
document
and
what
we
did
now
is
a
split
that
work
would
keep
the
requirements
in
the
previous
document,
which
mimics
what
we
did
in
RFC
1864,
and
this
one
is
a
peace
document
of
49:41
next
slide.
K
K
Then
it
also
recommends
to
use
the
same
interface
identifier
for
multiple
prefixes.
So
obviously,
if
you
use
the
same
interface
ID
for
multiple
prefixes
that
allows
the
collection
of
network
activity
between
those
two
addresses
also
the
same
interface
identifiers
move
its
employees
reused
when
they,
you
know
no
moves
from
one
network
to
another.
K
What
we
did
was
when
it
comes
to
the
algorithm,
keep
everything
keep
all
the
text
that
has
to
do
when
the
addresses
are
generated,
the
timing
and
so
on,
and
but
replace
the
algorithm
itself
that
you
use
to
compute.
The
interface
ID
for
many
different
reasons
among
them
is
that,
for
example,
the
algorithm
mandated
to
not
set
the
universal
local
beat
according
to
the
specs
at
the
time
and
that
changing,
etc,
etc,
etc.
K
K
The
second
one
is
essentially
a
modification
of
70
to
17,
in
which
you
are,
for
example,
a
time
parameter
so
that
you
can
essentially
use
exactly
the
same
algorithm
with
these
mineral
modifications.
So
you
don't
need
to
have
like
two
completely
different
algorithms
for
stable
or
for
a
temporary
address.
Again.
These
are
two
possible
alternative
algorithms.
We
are
not
saying
you
should
do
one
or
you
should
do
the
other,
but
here's
two
from
which
you
can
possibly
select
one
next
slide
and
same
question
as
before.
K
AG
AG
It
is
that
it
says
that
the
address,
presumably
the
next
interface
identifier,
must
not
be
the
same
as
the
previous
one
is
the
way
that
I'm
reading
it
and
I
think
that
that
has
to
I
think
that
needs
to
change,
because
it
suggests
that
a
host
implementation
would
have
to
remember
the
address
it
used
before
and
so
there's
just
a
wording,
change
I
think
we
can
say
instead
of
saying
it
must
be
different.
We
want
to
say
it
must
be
most
unlikely
that
it's
the
same.
AG
If
you
look
at
the
random
number
base
that
I
IDs
there's
ever
such
a
small
possibility
that
it
could
be
the
same,
and
we
want
that
because
if
you
don't
allow
it
to
sometimes
be
the
same,
then
you're
introducing
a
pattern
which
the
draft
later
says.
You
can't
introduce
a
pattern
because
it's
not
semantically
opaque
if
you're
remembering
something
about
waters
before
and
disallowing
specific
values,
and
then
that
happens
across
time
and
it
also
happens
across
space.
So
you
could
imagine
a
machine
having
hundreds.
There
are
hundreds
of
thousands
of
heidi's
on
it
simultaneously.
AG
It's
going
to
look
across
those
mean
you
don't
want
to
disallow
it
from
being
able
to
choose
one
of
the
addresses
it's
already
there,
because
that
makes
it
more
predictable
so
that
that's
what
I
was
talking
about
there,
it's
in
the
mailing
list
and
then
I
just
had
a
couple
other
suggestions
about
how
we
could
word
it.
But
ideas
make
it
something
that
an
implementer
could
actually
do
instead
of
saying
something:
that's
some
so
difficult
to
enforce.
AG
K
I
responded
to
your
thanks
for
the
comment
I.
What
women
is
that
identify?
It
should
be
statistically
different,
so
we
don't
want
that,
like
you
do
in
49:41,
in
which
you
just
generate
some
value
and
reuse
it
for
different
prefixes.
So
that's
essentially
what
we
meant,
and
we
also
we
don't
expect
you
to
actually
remember
about
previews
interface,
identifiers,
brain.
AG
K
What
I'm
saying
is
that
it's
not
that
we
expect
that
you
compare
the
interface
ID,
that
you
just
generated,
we
previous
ones
or
it's
just
that
we
yeah.
We
don't
want
you
to
reuse
the
same
interface,
identifier
deterministically.
So
that
means
that
it
should
be
statistically
different.
That's
what
I
don't
think.
AG
Z
F
Same
shine,
wouldn't
the
I
mean
you
say
you
don't
have
stable
storage,
but
wouldn't
the
existing
temporary
just
be
put
into
a
deprecated
State
for
a
period
of
times.
You'd
know
it
was
associated
with
the
hoster
anyway
I'm
a
little
confused
about
having
to
remember
it.
Sorry,
okay,
but
yeah,
I,
think
what
you
need
to
focus
on
is
the
property
of
the
address
you're
generating
not
on
relative
to
the
other
addresses
that
you
have
I.
F
Think
the
other
thing
that's
important,
I
think
that's
what's
happening
on
the
list
is
to
have
something
in
there
about
the
frequency
with
which
you
change
them.
I
know
there
is
something
on
49:41
about
that,
but
improving
that
would
certainly
be
a
good
thing.
I
think
most
operating
systems
you
tend
to
see
them,
flip
them
every
24
hours
for
something,
so
it
becomes
very
predictable
but
making
sure
that
that's
clear
that
varying
that
quite
significantly
is
a
good
thing.
Yeah.
W
Lorenza
quality
are
two
things
number
one
I
think
the
I
think
the
algorithm
based
on
$0.72
even
is
a
bad
idea,
because
it's
actually,
if
you
manage
to
figure
out
what
what
the
key
is.
It's
basically
predictable
from
now
until
the
end
of
time
and
depending
on
what
F
is,
if
it's
sort
of
not
secure
you,
you
sort
of
end
up
being
it
sort
of
ended
up
being
possible.
Even
if
you
don't
make
anything,
I
really
don't
see
what
get
what
that
gives
us
above
being
random,
particularly
in
the
presence
of
collisions.
W
The
other
thing
I
wanted
to
say,
is
I.
Think
it's
we
should.
We
should
maintain
somewhere
in
the
in
the
in
this,
in
the
specs
of
the
possibility
of
using
slack
with
a
with
a
randomized
MAC
address
for
simple
implementations,
because
right
now,
like
we
have
this
distinction
between
temporary
and
stable
and
that
sort
of
address
is
neither
a
temporary
nor
stable.
S
K
There
are
like
there
are
two
different
documents,
so
the
first
one,
which
is
the
one
on
non
stable
interface
identifiers,
essentially
sets
the
requirements,
and
as
long
as
you
comply
with
those
requirements,
you
are
fine,
then
49:41
B
is
specify
some
algorithm
that
you
know
can
comply
with
those
requirements,
so
the
requirements
and
the
possible
algorithms
to
comply
with
those
requirements
are
separate.
So
you
could
implement
your
own.
If
you
want,
you
don't
need
to
follow
the
specific
algorithms
that
we
are
giving
you
as
examples,
but
still
that's
that's.
C
K
C
K
E
E
E
Ok,
so
I
can
probably
like
run
49-41
through
it
and
give
the
XML,
so
you
can
use
as
0
1
so
like,
but
the
right
way
Bob
like
personally,
like
you
know
what
I
like
on
abyss,
is
the
changelog
right
like
like
you
did
for,
like
you
know
the
1981
so
like
80
200,
so
I
think
like.
That
would
be
like
really
good.
If
you
have
it
just
a
change
like
all
the
things
you
do
in
addition
to
this,
like
it.
K
E
I
understand
but
like
I
think
like
Bob
was
saying
like
the
baseline
is
not
for
United
41
I.
Think
he's
not
saying,
like
anything
else,
he's
just
saying
like
the
the
zero
zero
of
this
should
be
identical
to
funneling
41
and
then
all
the
changes
not
really
anything
else,
he's
nothing
anything
else.
The.
C
A
W
Let's
delete
the
text
that
says
requirements
on
algorithms,
let's
just
say
it
needs
to
be
random.
It's
just
easier
for
everyone
to
understand
and
there's
no
risk
of
putting
an
algorithm
that
the
developer
thinks
satisfies
the
requirements,
but
doesn't
actually
do
to
do
yeah
exactly.
Let's
just
say
it
needs
to
be
random
period.
Okay,.
AH
Okay,
next
one,
please,
okay,
so
what.
AH
Okay,
so
what
we'll
see
the
problem?
Why
this
draft
came
about
and
many
om
functions?
There
require
identification
of
not
only
source
but
the
path
used
and
that's
especially
important
in
segment
routing,
so
segment
wrong.
Pv6
does
provide
with
the
use
of
segment
routing
extension,
header
and
compliance
with
this
requirement
as
segment
routing
an
imperialist
data
plane
as
well
as
unified
the
star
which
effectively
is
a
sir
MPLS
over
UDP
is
not
on
other
hand.
Scalability
of
SR
with
ipv6
network
is
a
concern
because
of
use
of
128-bit
long
sits
altered
other
hand.
AH
Is
that
a
certain
bill
s
because
it
uses
MPLS
identifier,
a
20-bit
identifiers
is
much
more
scalable,
especially
if
we
want
to
encode
service
function,
intercept
IDs
and
to
support
this
is
that
IGP
extensions
for
the
segment
rollin
already
are
capable
advertising
20
bit
long
seeds
as
well
as
32
bits
long
seeds.
So
what
we
propose?
We
propose
to
make
segments
routing
header
multifunctional,
not
only
be
capable
advertising
128-bit
seeds,
but
be
able
to
recognize
that
it
carries
either
20
bits
or
32
bits.
It's.
AH
Solution
is
pretty
simple
alakay
to
beat
wrong
as
held,
which
can
be
encoded
as
0
for
128
to
be
compatible
with
current
implementations
that
the
current
draft
suggests
that
this
field
to
be
0
on
transmission
and
ignored
on
receipt
and
use
two
values
for
encoding,
20
bits
and
32
bits
it's
and
then
leave
one
more
for
future
use.
So
the
transit
SR
nodes
will
operate
the
same
way
as
described
in
a
segment
routing
header
draft
and
ingresses
are
no.
The
definition
will
be
provided
in
the
future
updates.
AH
AH
AH
Ok,
I
think
that
if
you
have
your
own
I
personally
think
that
it's
probably
belong
here,
because
it
proposes
update
to
the
format
defined
in
this
group.
But
I
agree
that
spring
working
group
should
be
informed
and
be
aware
of
any
decision
made
on
test-taking
for
this
draft,
whether
it's
merged
to
existing
draft
or
decided
to
be
independent
draft.
So.
I
I
So
I
I,
don't
think
you're
at
a
point
where,
where
you
can
ask
either
of
those
questions
yet
I
guess
I
don't
see
how
this
would
get
used
in
actually
any
any
use
case
right
now,
not
that
not
they
can't
be
but
I,
don't
you
haven't
described
any
of
that,
so
I,
don't
I,
don't
think
we're
there
that
you
want
to
keep
building
on
it
on
the
on
the
on
the
list
or
issue
some
more
versions
of
it.
Maybe
that
should
be
the
path
you
take
and.