►
From YouTube: IETF108-6MAN-20200731-1300
Description
6MAN meeting session at IETF108
2020/07/31 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
All
right,
it
is
time
to
start.
It
is
now
p.m.
Utc
6
a.m.
For
me,
so
welcome
to
six
man.
This
is
our
second
session
at
itf
108..
Today
we
have,
we
have
the
agenda
up.
We
have
first
to
talk
about
working
group,
draft
the
minimum
path,
mtu
hop
option,
and
then
we
have
talks
on
three
new
individual
drafts
and
we
will
try
to
manage
the
time
to
get
through
all
of
this,
and
so
why
don't
any
there's,
not
any
questions
we
will
start.
A
A
We've
done
that
for
the
last
couple
of
years,
because
they're
new
new
working
group
drafts
I
mean
today,
I
think
we
will
get
through
the
time,
but
we've
we've
always
done
that
for
for
it
gives
lower
priority
to
new
drafts.
That
haven't
had
a
lot
of
discussion,
but
so
you're
saying
you,
you
had
them
when
you
were
planning
for
the
time.
C
D
Perfect,
I
won't
be
sending
video
today
because
my
dsl
line
is
literally
in
a
tree
at
the
moment
and
hopefully
you
will
run
the
slides
and
I
will
tell
you
want
to
play
next.
D
I
think
the
first
two
slides
are:
oh
there
is
you
skip
the
title
slide.
I
see
perfect
well
to
introduce
myself
so
I'm
anna,
I
work
with
gory
fairhurst
at
the
university
of
aberdeen.
D
D
D
Oh
right,
that's
not
ideal,
but
okay,
so
we
have
a
need
to
do
a
lot
of
non-standard
measurements
that
have
to
do
with
setting
packet
bits
or
using
different
types
of
headers
like
ipv6
extension
headers,
and
often
we
try
to
do
this
from
as
many
vantage
points
as
we
can.
D
D
They
run
linux
they're
configured
as
a
fleet
with
ansible,
and
we
currently
have
four
of
them.
One
is
at
the
university
of
aberdeen
and
then
we
have
another
three
that
are
hosted
by
some
very
kind
people
which
some
of
which
hopefully
are
listening
and
they're
in
various
places.
We
have
one
in
the
janet
slough
data
center
in
the
uk,
and
this
one
is
hosted
by
team
cho,
and
then
we
have
two
others
in
california,
one
hosted
by
bob
and
one
hosted
by
warren
kumari.
D
We
are
definitely
interested
in
deploying
more
and
run
more
experiments
from
more
places.
So
if
you
want
to
host
one
of
these
get
in
touch
with
me
or
gory,
and
I
will
also
have
some
more
details
at
the
end
of
the
presentation
as
well,
so
we
use
these
probes
to
run
ipv6
extension,
header
experiments
and
if
we
go
on
to
the
next
slide,
or
rather
two
slides
onwards,
to
slide
number
three,
I
will
tell
you
all
about
them.
D
Yes,
perfect.
So
specifically,
we
did
tests
with
hop
by
hop
options
and
with
destination
options.
D
We
did
two
types
of
tests:
end-to-end
traversal
tests,
where
we
send
the
dns
queries
to
20,
000
name
servers,
and
we
look
for
our
dns
responses
and
we
also
did
trace
root
style
tests
where
we
send
icmp
messages,
starting
with
a
hop
limit
of
one
and
increasing
it
each
round.
And
then
we
record
replies
from
routers
on
the
path
each
and
every
measurement
we
start
by
sending
a
vanilla
packet
that
has
no
extension
header,
and
this
provides
us
with
a
control
measurements
that
we
can
then
compare
against
so
for
each
target.
D
D
Here
I
tell
you
what
goes
in
the
extension
header.
Well,
we
for
the
end-to-end
reversal
tests.
We
tried
different
things.
We
try
to
set
send
a
valid
pad
n
option
which
just
stands
for
bytes
of
padding.
This
is
well
known,
option
that
returns
on
the
path
understand,
and
this
is
why
we
wanted
to
test
it.
We
then
tried
to
send
an
invalid
pad
and
option
as
well
to
see
if
that
makes
it
by
invalid.
I
mean
it
says
it
sends
eight
bytes
of
padding,
but
in
fact
it
only
sends
four.
D
D
So
if
we
move
on
to
the
next
slide
before
we
dive
into
the
results,
I
will
basically
just
try
to
categorize
what
happens
when
you
send
a
packet
with
an
option
or
with
an
extension
header.
Rather
so
you
either
get
a
reply
from
the
destination
in
our
case
for
the
end-to-end
traversal
test.
This
would
be
a
dns
response
and
then
you
consider
the
transact
or
the
traversal
successful
or
the
packet
can
be
silently
dropped,
either
by
the
destination
or
somewhere
along
the
path.
D
When
the
packet
is
dropped,
then
whatever
drops,
it
can
also
send
back
an
icmp
unreachable
message
that
would
quote
the
packet
as
it
was
received
at
the
hop
that
dropped
it.
But
I'm
going
to
talk
about
the
the
first
case
here,
the
case
where
we
actually
got
an
answer
to
our
dns
query.
D
D
D
The
story
was
nuts
is
not
so
great
for
hope
by
hop
options
where
it
seems
to
depend
drastically.
On
the
vantage
point,
for
example,
no
packets,
with
the
hop
by
hop
option
had
to
receive
the
response
because
they
never
made
it
outside
of
the
comcast
network.
Well,
in
the
case
of
bob's
probe,
so
from
bob's
house,
we
did
not
look
at
other
home
access
networks,
but
we
plan
to
well.
D
What
we
also
found
is
that
an
invalid
pad
and
option
the
one
that
advertises
a
different
length
than
the
one
it
sends
does
not
actually
traverse
the
path
at
all.
D
We,
I
also
mentioned
testing
with
the
minimum
path
mtu
option.
So
the
good
news
is
that,
while
it
is
an
unknown
option,
it
has
a
very
similar
traversal
rate
to
that
of
a
pad
and
option
which
is
well
known.
So
the
routers
who
forward
options
will
forward
the
packet
anyway,
even
if
it
has
an
option
that
is
not
known
so
now
to
look
at
the
numbers
we
can
go
on
to
the
next
slide.
D
Okay,
so
here
you
have
traversal
numbers
for
hop,
ihop
destination
options
from
february
and
july,
so
I
guess
here
you
can
see
how
we
get
consistent
results
for
destination
options,
but
not
hoped
by
hope
options
like
just
like
I
presented
in
the
previous
slide.
We
can
see
that
nothing
not
much
has
changed
between
february
and
july,
and
we
can
also
see
that
a
lot
of
packets
with
options
actually
get
dropped.
D
So
the
next
step
was
to
look
at
where
this
happens
in
the
network,
and
if
we
go
on
to
the
next
slide,
I
will
move
on
to
talking
about
the
results
that
we
got
from
the
tracer
style
measurements
now.
So
these
measurements
are
done
by
sending
icmp
packets
with
increasing
hop
limit
values,
and
if
a
router
can't
decrement
the
hop
limit
and
forward
the
packet,
then
it
sends
us
back
an
icmp
hop
limit
exceeded
in
transit
packet.
This
quotes
the
original
packet
as
it
arrived
at
the
router.
D
This
means
that
for
each
measurement
we
can
look
at
whether
or
not
the
packet
was
altered
and
we
actually,
what
we
found
is
that
nothing
changes.
Nothing
along
the
path
seems
to
change
the
pattern
option
we
sent
so
the
routers
on
the
path
did
not
tamper
and
modify
the
extension
header.
D
However,
we
did
find
one
hop
that
completely
removed
the
extension
header
and
removed
it
entirely,
and
this
ip
address
seems
to
belong
to
information
and
computing
technology
services
for
tertiary
institutions.
In
hong
kong.
D
It
must
be
some
sort
of
packet
normalizer
box,
but
yes,
this
case.
This
is
the
case,
and
this
happened
now.
Another
thing
to
note
is
that
when
sending
these
packets,
I
make
a
note
of
the
of
the
hop
limit
that
the
packet
was
initially
sent
with
and
encode
this
in
the
icmp
payload
of
the
packet,
so
that
we
are
able
to
extract
it
when
the
packet
is
coded
back
to
us
from
routers
on
the
path.
D
So
I
guess,
for
each
measurement,
the
largest
hop
limit
that
is
returned
to
us
essentially
tells
us
how
many
hops
the
packet
made
it
along
a
longer
path
before
it
was
discarded.
So
for
every
single
measurement.
We
made
a
note
of
the
number
of
hops
each
packet
reversed
and
we
averaged
them,
and
this
is
something
we
can
see
on
the
next
slide.
D
So
surprisingly,
it
looks
like
packets
with
destination
options
actually
make
it
almost
as
far
into
the
path
as
packets,
without
any
extension
header
at
all.
You
see.
The
number
are
very,
very
similar
for
the
control
probe
that
we
sent
and
for
the
destination
options
options
probe
that
we
sent.
So
this
tells
us
that
the
drop
actually
happens
very
close
to
the
destination
or
even
at
the
destination
in
the
destination,
as
in
any
case
so
while
destination
option
packets
are
probably
discarded
at
the
server
edge
hope.
D
I
hope
options
seem
to
be
discarded
a
couple
of
hops
earlier,
but
surprisingly,
they
also
still
have
a
chance
of
making
it
quite
far
along
a
path
before
being
dropped
so
and
the
average
here
was
14
hops
before
either
before
being
dropped
ahead
of
receiving
a
reply.
D
You
see
here
the
results
from
one
vantage
point
which
is
from
aberdeen,
but
this
was
actually
a
case
for
every
other
site,
well
from
bob's
house,
where
the
average
number
of
hops
that
the
packet
would
hop
by
hop
options
reverses
around
three,
because
the
pack
is
never
make
it
out
of
the
comcast
network
right.
So,
if
you
move
on
to
the
next
slide,
I
can
tell
you
all
about
what
we
learned
so
far.
D
Well,
the
packets
with
options
travel
quite
far
across
the
internet
past
we
looked
at.
However,
we
didn't
many,
we
didn't
measure
many
access
networks
and
we
need
more
info
here.
D
We'd
like
to
measure
more
of
those.
We
also
only
tested
the
dns,
so
we
only
tested
udp
and
icmp.
D
We
did
not
test
tcp,
but
so
we
don't
know
if
there's
a
difference,
but
this
is
also
something
to
keep
in
mind
and
look
at
later
when
the
packets
are
forwarded,
in
some
cases
up
to
42
percent,
they
reach
the
destination
and
they
can
be
used
by
an
algorithm
such
as
the
dpl
pmg
d1,
but
in
most
cases
they
are
actually
silently
dropped
and
because,
because
of
this
high
drop
rate,
we
probably
options
should
be
sent
on
standalone
probe
packets
rather
than
on
packets.
D
That
would
impact
the
flow
in
case
they
were
lost.
This
relates
to
some
files
to
how
some
firewalls
are
configured
by
default.
So,
for
example,
you
have
pf,
which
is
the
default
firewall
for
openbsd
and
also
it.
It
forms
part
of
freebsd
as
well,
and
there
are
many
commercial
firewalls
that
are
based
on
these
and
pf,
for
example,
drops
packets
with
some
extension
headers
by
default,
and
you
have
to
enable
them
to
let
them
through.
D
So
that's
ipfw,
which
is
the
main
firewall
in
freebsd,
but
it
only
only
does
this
with
unknown
options,
but
also
I
mentioned
earlier
how,
when,
when
a
packet
is
dropped,
it
can
send
back
an
icmp
unreachable
message,
and
that
would
give
us
some
sort
of
insight
into
what
happened
to
the
option
along
along
the
path
and
if
we
it
would
require,
it
could
record
a
partial
partial
value
that
we
can
maybe
use
for
an
algorithm.
However,
most
firewalls
actually
will
not
give
you
back
an
icmp
unreachable
message.
D
D
D
D
Well,
the
packets
that
carry
the
option
should
be
chosen
quite
carefully
to
avoid
potentially
throwing
away
important
packets
in
the
flow.
So
we
want
to
advise
setting
this
option
on
a
probe
packet
rather
than
a
package
in
the
flow,
then
other
option.
Other
aspects
of
the
proposed
option
are
those
that
apply
to
options
in
general,
I
mean:
do
we
incur
additional
processing
in
the
network,
or
do
we
potentially
take
away
space
from
other
options,
but
this
is
a
very
small
option,
with
a
very
small
processing
cost
per
packet.
D
So
this
seems
like
a
very
like
this
does
not
seem
like
a
concern.
D
Another
issue
is
the
need
for
some
on
path
validation,
so
the
information
should
be
used
more
as
a
hint,
rather
than
something
that
directly
drives
a
change,
but
I
guess
finally,
a
barrier
to
deployment
of
the
hope
by
hop
option
is
the
fact
that
of
well
of
the
minimum
path
in
q1
is
the
fact
that
the
protocol
stacks
this
is
not
currently
implemented.
Protocol
stacks
don't
currently
have
an
api
that
can
set
or
receive
the
information
in
a
useful
way.
D
D
D
Well,
as
you
can
see,
we've
had
quite
a
lot
of
insights
into
options
reversal
with
these
probes,
but
we
don't
have
nearly
enough
data
from
edge
networks
and
we
would
love.
We
would
absolutely
love
to
do
more
experiments,
so
I
know
an
option,
for
this
would
be
ripe
atlas,
because
there
are
many,
many
probes
that
are
ipv6
enabled
and
in
edge
networks.
So
if
you
can
help
us
run
this
kind
of
test
on
ripe
atlas
probes,
that
would
be.
D
That
would
be
great
because
I
don't
think
it's
part
of
their
normal
suite
of
tests,
but
also
if
anyone
listening
would
like
to
host
a
probe
or
a
virtual
probe.
D
I
can
give
you
basically
a
vm
image
and
you
can
deploy
this
in
your
data
center
and
please
get
in
touch
if
you
can
do
so.
That
would
be
great
also
if
you've
done
your
own
measurements
and
have
some
data
to
share
we'd,
absolutely
love
to
hear
from
you-
and
that
concludes
my
presentation.
Hopefully
gory
is
around
here
somewhere
to
help
me
answer
any
questions.
C
Yeah
so,
first
of
all,
anna.
Thank
you
so
much
for
this
presentation.
It's
really
a
hot
topic
and
I'm
fully
support
you
up
to
the
point
of
hosting
a
container,
not
a
vm,
though
in
my
edge
network
or
in
right.
My
only
concern
in
this
study
is
that
there
is
a
heavy
bias
towards
dns
server,
which
are
typically
hosted
into
big
data
center
environment.
D
Yes,
absolutely
we
would
love
to
also
diversify
the
test,
video,
which
is
why
it's,
I
think
the
next
big
step
would
be
to
add
tcp
support
in
the
software
that
we
use
to
run
the
experiments
and
do
this
towards
web
servers
as
well.
I
guess
go
on
sorry.
C
I
just
want
to
say
I
would
love
as
well
to
get
a
wall
of
shame
of
people
dropping
those
legal
ipv6
packets,
so
that
you
could
be
cool
now.
I
do
not
think
honestly
that
it's
probably
a
proposed
standards
in
six
man
rather
than
informational
and
v6
ops,
but
it's
just
a
personal
comment,
of
course,
good
job
again
right,
don't
take
me
wrong.
F
B
D
A
F
A
F
We
should
say
that
we
plan
to
revise
this
document
and
bring
it
back
to
the
working
group
and
continue
working
on
it,
and
we
just
got
a
release
of
the
provisional
assignment.
Let
us
do
that.
A
Okay,
I
think
you
were
breaking
up,
but
I
think
I
heard
you
were
planning
to
revise
the
document
and
bring
it
back
to
the
working
group.
A
A
G
Can
you
hear
me
yes
great,
so
I'm
going
to
talk
about
extension
header
attribution
option.
There
is
a
draft
on
this
that
we
recently
updated
our
next
next
screen.
Please.
G
So
the
motivation
for
this
is
that
we
want
to
be
able
to
enable
extension,
header,
insertion
and
removal
in
flight.
This
has
obviously
been
a
topic
that
has
generated
a
lot
of
discussion
in
six
man.
First,
it
was,
I
guess,
started
by
some
of
the
needs
for
segment
routing,
but
we're
also
finding
that
iom
and
qos
probably
need
this.
The
basic
idea
is
that
packets,
as
they
ingress
a
limited
domain,
may
be
annotated
with
data
and
that
data
would
take
the
form
of
extension,
headers
typically
help
by
hop
options
or
segment.
G
As
we
know,
extension
headers,
for
instance,
on
the
internet,
are
not
extremely
reliable.
At
this
point,
I
think
there's
a
few
examples
of
this.
As
I
mentioned
for
hop,
I
hop
options.
Ioam
is
being
defined
and
would
be
quite
useful
for
an
operator
to
remember
packets
transiting
their
domain
there's
also
a
new
initiative
called
network
tokens.
This
is
very
similar
to
something
that
I
had
done
called
fast.
G
As
I
mentioned,
segment
routing
was
kind
of
the
poster
child
use
case
of
this
and,
in
addition
to
segment
routing
headers,
that
would
also
kind
of
imply
that
we'd
want
destination
options
before
the
routing
header,
so
those
are
probably
the
the
three
types
of
extension
headers
that
are
most
applicable
here.
I
don't
think
that
fragmentation
or
ipsec
security
would
be
applicable
next
slide.
Please.
G
So
I'll
just
do
a
quick,
quick
overview
of
the
problems
that
we've
identified
with
extension
head
or
insertion
and
then
try
to
show
how
we're
going
to
address
those
or
at
least
mitigate
them.
G
For
that
reason,
the
other
problem
that
we
have
is-
and
we
saw
this
with
segment
routing,
there's
no
way
to
know
which
headers
were
inserted.
G
If
we
just
insert
a
hop
by
hop
option,
for
instance,
we
if
we
and
we
want
to
remove
it-
we
wouldn't
know
for
certain
whether
that
was
actually
created
by
the
source
or
inserted
by
the
network.
So,
there's
an
ambiguity
there
that
we'd
have
to
resolve
it
breaks
path,
computer
recovery
in
particular,
for
inserting
new
data
into
the
packet
that
increases
the
packet
size
and
that
runs
the
risk
of
packet
loss
later
on
in
the
stream,
where
we
exceed
an
mtu.
G
G
Another
issue
is:
there's
no
feedback
when
a
node
inserts
data
headers
and
it
causes
downstream
drops,
and
it
also
breaks
in
the
sense
that
if,
if
there's
inserted
data
and
does
the
computation
over
that
data,
it
will
obviously
fail
in
the
computation
next,
please.
G
So
often
when
this
topic
is
brought
up,
ipip
encapsulation
is
the
suggested
alternative.
In
fact,
I
think
in
the
early
versions
of
drastic
rfc
8200,
this
was
actually
mentioned
as
being
the
kind
of
the
official
alternative.
There
are
some
problems
with
this.
First
of
all,
this
requires
that
we
set
a
destination
address
to
the
encapsulating
device
when
the
for
device
encapsulates
and
a
lot
of
instances
that
might
not
be
known
in
segment
routing,
it's
kind
of
implicit
because
the
source
is
actually
doing
source
routing.
G
G
On
the
other
hand,
ipip
encapsulation
fundamentally
changes
it.
So
packets
that
have
extension,
headers
insert
it
take
a
very
different
route
than
those
that
are
using
ipm
ip
encapsulation
to
try
to
accomplish
the
same
effect
and
then,
lastly,
there's
more
overhead.
When
we're
doing
header
insertion
and
the
worst
case
scenario,
it's
40
bytes
of
ipv6
header
next
flight,
please.
G
G
Data
length
has
three
fields,
so
the
e
field
indicates
that
an
extension
header
has
been
inserted
when
it's
set
and
that
follows,
and
then
null
mops
indicates
how
many
options
have
been
inserted
into
into
the
header
and
the
identifying
information
identification
identifies
the
node
responsible
for
inserting
the
data.
The
identification
can
be
considered
local.
So
in
some
cases
that
could
be
an
ipv6
address,
or
it
could
be
some
local
identifier.
If
you
want
to
minimize
the
space
in
the
hop
by
hop
option.
G
The
insertion
operation,
if
there's
no
destination
or
help
by
help
option,
we
will
insert
one
and
then
insert
the
options
following
that,
if
they're
already
existing
appropriate
extension
header,
we
will
insert
into
that
header
the
option
and
there's
two
possibilities
here.
One
is
we're
inserting
options
and
those
could
either
be
hot
by
hop
or
destination
options
before
the
routing
header,
in
which
case
this
would
apply.
G
The
second
case
is
when
we're
inserting
an
extension
header,
and
for
that
the
idea
is
that
we
always
proceed
inserted
extension
headers
by
a
destination
option
that
has
the
ebit
set
and
that
destination
option
could
include
other
inserted
options,
so
we
can
have
actually
one
option.
You
could
return
for
converted
extension,
headers
and
inserted
options
next
play.
Please.
A
Remove
you
were
just
about
out
of
time,
so
if
you
could.
G
Okay,
removal
operation:
it's
a
pop
model,
so
we
remove
options
in
the
reverse
order
that
they
were
inserted
and
the
other
thing
that
we
can
do
is
modify
implementations
to
logically
remove
inserted
data
before
computation.
So
that's
not
an
issue
with
that.
I
will
end
here.
A
G
G
So
the
I
posted
the
draft
upstream,
the
latest
version.
It
would
be
great
to
see
comments
and
I
am
intending
at
some
point
to
ask
for
working
group
adoption.
H
Yeah
I
had
a
question
tom.
The
the
assertion
that
inserting
headers
doesn't
change
the
ecmp
processing
kind
of
relies
upon.
The
fact
that
anything
is
trying
to
do
ecmp
would
continue
to
look
past
them
for
its,
like
ecmp
load,
balancing
information
like
trying
to
find
a
udp
header,
or
something
like
that
right.
G
Well,
it
does,
if
that's
the
way,
cmp
works.
If,
if
it's
using
the
ipv6
flow
label,
then
it
would
only
be
the
source
destination
and
flow
label,
so
that
would
work
in
without
requiring
dpi
if
the
devices
are
due
dpi,
which
obviously
many
of
them
do,
that
would
depend
on.
They
have
the
capability
to
parse
over
the
hop
by
hop
option.
Extension
header,
if
they're
not
doing
that,
then
they're
kind
of
breaking
ipv6
anyway.
H
G
Well,
well
it
it,
it
is
if
the
ecmp
processing
is
correct,
because
the
say,
for
instance,
hop
by
hop
options,
insert
it
as
long
as
the
devices
parse
over
the
hop
hop
option,
they
can
still
extract
the
transport
ports
and
they
still
have
the
ips
ipv6
addresses.
G
G
Okay,
so
this
this
is
a
separate
problem
that
that
I
think
is
coming
up.
Also,
this
is
the
so-called
parsing
buffer
problem,
but
I
would
point
out
that,
since
this
is
in
a
limited
domain,
presumably
the
the
admin
would
address
all
of
these
issues.
So
it's
a
controlled
domain,
so
they
they
can.
They
can
assure
that.
C
A
Okay,
can
you
hear
me
we
can.
I
Great
okay,
hello:
I
am
going
to
present
this
beer
in
six
strat
on
behalf
of
our
co-authors,
from
zte,
juniper,
cisco,
nokia
and
future
way.
Next,.
A
I
Yeah
I'll,
try,
yeah,
so
beer
means
beat
index
explicit
replication.
It's
a
new
technology
that
achieves
efficient
multicast
distribution
without
requiring
a
per
flow
state
in
the
network.
I
I
So
rxc8279
talks
about
the
arc
architecture
for
beer
has
three
lower
the
multicast
flow
overlay
that
basically
helps
the
determining
which
bits
bits
needs
to
be
set
and
the
beer
layer
that
does
the
boarding
and
the
routing
underlay
basically
provides
a
path
to
reach
to
the
next
half
of
the
efforts
next
slide.
Please.
I
I'm
going
to
escape
the
the
details
of
beer
header.
The
key
is
that
there
is
a
bit
string
and
and
other
information
in
the
beer
header.
Now,
let's
move
on
on
to
the
next
slide
to
see
how
beer
could
be
implemented
in
an
ipv6
only
network.
I
In
this
network
I
have
routers
a
b
c
d
e,
f,
router,
a
gets
a
multicast
package
and
in
the
list
of
four
to
edge
routers
d,
f
and
e
and
from
the
multicast
flow
overlay.
It
determines
that
the
fp
needs
to
receive
the
traffic.
So
it
says
three
bits
in
those
in
the
bit
string.
I
It
puts
on
that
blue
header,
and
now
it
needs
to
put
down
a
next
header,
an
outer
header,
so
a
and
b
are
directly
connected,
so
it
could
just
put
on
a
ethernet
header
there
when
b
gets
it.
It
in
arabic
is
traffic
to
c
and
e,
because
it
forms
a
bit
string.
It
knows
that
it
needs
to
send
a
packet
of
c
and
e.
I
So,
instead
of
c,
you
could
just
put
down
like
either
ethernet
header
and
by
when
it's
sent
to
e,
for
whatever
reason
it
could
decide
that
it's
going
to
put
on
an
ipv6
header
before
the
event
header,
it
does
not
matter
what
the
outer
header
you
use
after
the
ear
header,
it
could
be
ipv6
header,
it
could
be
either
header
or
could
be
anything,
and
that
somehow
makes
sense
next
slide,
please.
I
So
in
this
picture
there
is
a
slight
difference
there
here
that
router
b
is
incapable
incapable
of
doing
beer.
So
the
router
a
needs,
the
tunnel
of
the
package
to
c
now
being
an
ipv6
network,
it's
most
natural
to
use
the
ipv6
header
after
the
beer
header.
But
again
it
does
not
really
matter
somehow
that
it
says
that
I
want
to
do.
Dre
yes,
insert
gre
header
between
the
ipv6
and
the
beer.
Header,
that's
also
fine,
and
so
basically
to
to
be
here.
Ipv6
is
just
outer
encaps
and
ipv6.
I
I
So
what
what
we
need
here
is
basically
a
cold
coin,
to
say
that
next
header
is
beer
and
that
is
consistent
with
general
beer
architecture
and
consistent
with
the
general
ipv6
iv
architecture.
I
So
next
slide.
J
I
A
I
Oh
I'm
sorry,
I
didn't
make
this
clear,
so
the
intent
in
the
home
for
this
draft
would
be
a
a
beer
working
group,
but
because
it
involves
ipv6
network.
We
want
to
present
it
here
to
to
get
people's
comments
here
and
and
also
there
are
other
options
proposals
to
to
do
beer
in
ipv6,
and
this
is
one
way
to
do
it.
B
B
I
A
Okay,
good:
we
can
continue
this
on
the
mailing
list,
so
next
presentation.
I
K
K
So
in
order
to
make
sure
the
service
is
processed
appropriately
in
the
network,
the
information
of
this
associated
rating
needs
to
be
carried
in
the
data
packet
so
that
each
hop
eyes
hop.
The
nodes
cancel
the
packet
to
the
set
of
resources
allocated
to
the
vtn
for
the
packet
processing.
K
So
in
this
document
we
propose
to
carry
this
rating
identifier
in
the
ipv6
extension
headers,
so
that
it
can
be
used
for
ipv6
network
and
also
can
be
used
for
the
srv6
network.
Next.
A
L
Go
ahead,
so
this
draft
assumes
that
a
new
extent
that
an
identifier
in
the
packet
for
the
vtn
is
needed
and
then
marches
off,
to
try
to
figure
out
how
to
create
one
and
uses
it
for
forwarding
in
ways
that
seem
prone
to
loops.
But
before
one
gets
to
the
problems
with
the
details
of
the
solution,
I
question
the
premise:
it
is
not
at
all
obvious,
even
if
one
wants
to
do
binding
to
resources,
which
I
grant
one
wants
to
do,
that.
K
Okay,
I
think
I
got
a
question,
but
can
we
finish
this
presentation
first,
because
I
have
only
a
few
minutes
left.
K
Okay,
thank
you.
Basically,
in
this
draft
we
define
a
new
ipv6
extension
header
option
to
carry
this
waiting
id
to
fill.
The
format
is
showing
this
figure
and
it
can
be
escaped
with
and
recognized,
and
it
cannot
be
changed
in
the
in
pass
and
waiting
ideas
for
octet
lens
to
match
the
length
of
the
android
slides
identified
in
the
wireless
networks,
because
we
need
this
medium
idb
precisely
on
each
hop
along
the
path.
So
it
is
recommended
to
carry
this
vt9
option
in
the
extension
headers,
which
can
be
processed
the
hub.
K
Slide
so
here
are
the
procedures.
First,
the
reading
id
option
is
inserted
on
the
ingress
node
of
the
ipv6
or
i76
domain
as
an
option
in
the
outer
ipv6
header,
based
on
some
traffic
classification
or
mapping
policy
of
the
operator
and
along
the
past.
The
nodes
which
can
pass
this
rating
option
should
use
this
waiting
id
to
identify
the
vtn
packet,
belongs
to
and
use
the
local
resources
allocated
to
the
vtn
for
packet
processing.
K
K
A
C
K
Oh,
I
guess
joe
has
the
question
about
why
we
need
a
waiting
id
to
you
know,
use
the
for
the
packet
forwarding
right.
I
think
I
already
replied
to
his
email
in
the
middle
list.
Think
this
making
id
has
a
different
functionality
as
the
dsap,
which
has
been
used
to
differentiate
the
traffic
classes
and
the
priorities.
The
waiting
id
is
another
kind
of
identifier
to
identify
the
virtual
networks
and
they
don't
have
a
priority
between
each
other.
We
first
identified
the
vitian
virgin
transfer
network.
K
A
A
M
Hello:
everyone:
this
draft
propose
a
solution
of
nexus
that
please.
M
Another
well
managed
network,
no
ip
list
available.
So
how
can
we
know
which
ip
address
has
have
been
used
in
our
ipv6?
Ip
scan
is
effective,
but
on
ipv
ip4
episode
is
effective,
but
on
ip6
mission
impossible.
So
this
draft
proposes
a
solution
nexus
space.
M
On
first
step
set
up
a
collection
point
second,
step
append.
The
collection
point
address
to
the
router
advertisement
so
that
this
information
can
be
flooded
to
network
nodes.
Router
advertisement
should
be
extended,
type
is
set
to
13
9,
we
define
39.
The
connection
point
option
type
also
set
the
ipv6
address
or
collection
point
when
a
router
receives
router
advertisement
and
finds
that
there
is
a
collection
point
address,
the
router
needs
to
record
the
collection
point
address
and
then
next
time
the
router
sends
router
advertisement
collection
point
address
should
be
attached
in
this
way.
M
The
third
step
is
that
when
the
collection
pointer
receives
messages
from
hosts
and
routers,
it
should
get
the
source
address
of
this
message
and
the
record
addresses
with
timestamp
finally
collection
pointer,
get
a
list
of
online
ipv6
nodes
by
using
timestamp
online
address
list
can
be
updated,
so
this
this
is
the
the
solution.
The
draft
proposed
next
slide.
A
Yes,
so
thank
you.
I
don't
we're
about
out
of
time,
so
I
think
we
can
defer
any
more
discussion
on
this
to
the
mailing
list.
So
thank
you
so
that
wraps
up
today's
second
six-man
session.
Thank
you
all
very
much.
A
I
think
it's
almost
the
end
of
the
itf
week
and
I
suspect
we're
gonna
get
to
do
this
again
in
november,
but
who
can
tell
maybe
someday
we'll
get
to
meet
face-to-face
again,
but
I
doubt
it's
going
to
be
this
year
so
oli
and
I
thank
you
very
much
and
we'll
see
you
on
the
internet
for
real.
Thank
you.