►
From YouTube: IETF112-6MAN-20211109-1600
Description
6MAN meeting session at IETF112
2021/11/09 1600
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
I
think
we
have
enough
people
to
get
started
next
slide
holy.
A
A
A
We
don't
have
an
official
jabra,
scribe
sort
of
doesn't
seem
that
it's
necessary,
and
this
is
the
link
to
find
the
presentations,
and
I
think,
there's
also
a
link
in
mideco
next
slide
and
we
have
uploaded
all
the
slides.
So
if
you
are
a
speaker,
you
can
choose
your
slide
deck
from
the
prepared,
slides.
A
We
will
try
doing
this.
If
this
fails,
then
we
can.
We
can
share
them,
but
it's
easier
this
way
you
can
advance
the
slide
yourself.
A
This
is
the
agenda
for
today
introductions
what
you're
doing
now
document
status,
I'm
going
to
talk
about
the
joint
friday
session,
we're
having
with
v6
ops
in
a
minute,
then
eric
and
shiresh
are
going
to
talk
about
sids
and
ipv6.
Addressing
the
output
of
the
spring
adoption
call
on
the
compression
drafts
we
have
one
working
group
draft
we're
going
to
do.
An
update
on
giuseppe
is
going
to
do
that.
A
Not
seeing
any
so
this
is
the
agenda
for
the
joint
session,
with
v6
ops
on
friday
morning,
or
at
least
my
time
friday
morning,
bright
and
early,
but
the
general
idea
that
generated
this
is
that
both
working
groups
have
drafts
that
are
talking
about
top
by
hop
options.
A
You
know
the
processing
of
them
the
need
for
supporting
them
or
not,
and
so
after
some
discussion
with
the
ads
of
you,
know
the
internet
ads
and
the
ops
ids
sort
of
came
up
with
this
idea
of
having
a
joint
session
thinking,
it
might
bring
more
people
to
the
discussion,
maybe
particularly
outside
of
v6,
ops
and
six-man.
A
So
the
agenda
is
roughly
talking
about
the
requirements
and
solution
drafts
and
then
some
short
talks
on
some
current
proposals
for
hot
new
hop
options.
You
know
what
problem
they're
solving
and
then
just
a
discussion
about
you
know
what
people
think
about
the
hop
option
you
know:
can
we
make
it
work
better?
A
Is
there
some
other
way
of
doing
it?
What
to
do
with
the
existing
options?
Etcetera,
so
it
hopefully
will
be
an
interesting
session
on
friday.
Any
questions.
A
B
We
currently
have
no
documents
in
the
rfc
editor
queue,
but
we
had
three
documents
submitted
to
the
iesg
to
start
from
the
bottom:
the
minimum
path
mtu
option,
that's
with
with
eric
in
ada
evaluation,
but
the
two
other
two,
the
two
other
drafts
have
gone
through
the
esg
and
have
quite
a
few
discusses
and
iterations
the
alternate
marking
method.
We
will
talk
about
later,
so
guys
that
we
will
go
through
the
issues
he's
had
in
the
iterations
and
the
changes
that
has
happened
through
because
of
isg
review.
B
C
I
wanted
to
say
also
that
rfc
9131
was
the
was
our
first
document
to
go
through
the
rfc
editors.
Do
github
based
review
process
where
all
the
diffs
are
sent
by
github
and
it
was
an
interesting
experience.
I
think
I
found
it
helpful,
but
they're
still
running
other
experiments
to
see
how
they
can
improve
that
process.
So,
if
you're
you're
an
author
on
a
document,
beware
that
you
might
be
able
to
opt
into
this
experiment.
C
I
don't
know
what
their
intent
is.
I
think
they're
still
experimenting
but-
and
I
guess
it
kind
of
depends
on
the
number
of
of
authors,
because
you
need
to
get
all
the
authors
sort
of
set
up
to
use
the
github
review
flow.
But
I
found
the
ability
to
review
individual
diffs
in
github
much
easier
than
reviewing
lots
of
multi-indented
text
in
an
endless
email
chain,
with
different
people's
email,
editors,
putting
things
to
different
fonts
and
different
indent
levels,
and
so
on
and
so
forth.
So.
C
B
D
Delay
so
yeah,
just
in
a
few
words,
I
really
liked
it.
It
was
easiest
most
much
easiest,
then
yeah,
going
through
these
emails
and
trying
to
find
out.
If
I
missed
any
comments
so
yeah,
I
really
liked
it
strongly
recommended
and
it
was.
I
don't
know
it
was
an
experiment
experiment,
but
it
was
quite
simple:
easy,
no
issues
to
report
three
lessons.
B
Cool
excellent,
so
so
we'll
make
sure
that
we
recommend
that
the
authors
as
as
they
get
to
the
last
stage
of
the
process
thanks,
let's
see
so
document
stages,
two.
We
have
no
documents
waiting
for
working
group
adoption.
We
have
no
working
group
documents
and
we
have
no
documents
are
waiting
right
up.
That's
not
quite
true.
B
B
I
think
that's
all
so
suresh
and
eric
you're
up.
Do
you
want
to
share
your
own
slides
or
do
you
want
us
to
share
them?
For
you.
C
Oh
okay,
I
was
going
to
defer
to
you.
I
have
not
tried
this
presentation.
B
C
Do
you
want
me,
as
your
sheriff?
I
can
cheer
sure
there's
only
three
sides
anyway,.
C
Okay,
so
I
suppose
this
is
a
summary
of
what
we
what
has
transpired
in
the
last-
I
guess
maybe
three
to
three
and
a
half
weeks
of
some
back
and
forth
with
some
with
the
spring
on
some
compressed
discussion.
Next
slide,
please.
C
So
if
you
download
the
slides,
you
can
click
on
these
highlighted
things.
There
are
some
links
there.
There
is
inquiry
from
spring
to
six
man
about
compressed
sid,
behavior
and
some
sort
of
seed
behavior
in
general,
and
there
was
two
primary
questions,
both
of
which
were
sort
of
quite
lengthy
and
detailed.
C
Our
reply
was
lengthy
and
detailed,
and
we
raised
a
couple
of
issues.
One
was
that
there
was
some
lack
of
clarity
around
sids
and
what
their
semantic
requirements
are
in
certain
circumstances,
and
we
can.
We
can
talk
about
that
on
the
next
slide.
There's
also
a
an
issue.
C
Oh
sorry,
I'm
not,
I
said
yeah
can
you
go
back
one
and
the
meaning
the
semantic
meaning
of
segments
left
in
the
srh
looks
like
it
might
need
to
be
updated
or
something
will
have
to
be
done
to
sort
of
update
the
definition
because
it
doesn't
exactly
match
anymore.
It's
not
a
strict
index
into
the
sorry.
C
It
is
treated
as
a
strict
index
into
the
srh,
but
the
semantic
definition
is
actually
the
list
of
the
list
of
segments
left
so
where
the
list
of
segments
left
is
one
to
one
mapped
to
12856
addresses:
that's
that's
fine,
but
that
that
definition
is
now
drifting.
C
There
were
several
other
operational
concerns
about
whether
or
not
sorry
about
having
srh-less
packets
and
the
possibility
for
maybe
helping
sr.
V6
domain
fail
closed.
If
you're
interested
in
this,
I
think
much
of
this
discussion
will
be
happening
on
spring.
C
There
is
a
way
that
six
man
can
help
srv6
domains
to
fail
close,
and
we
can
talk
about
that
and
suresh
has
volunteered
to
be
the
the
lead
on
the
draft
for
us.
Thank
you
very
much
sresh
and
we're
talking
with
with
other
potential
co-authors.
So
I
think
next
slide
and
over
to
sresh.
G
Yeah
thanks
eric,
thank
you
and
yeah.
So
thank
you
very
much
for
putting
your
trust
in
me.
I
know
this
is
not
an
easy
topic,
and
somebody
explained
to
me
like
this
is
like
falling
on
a
grenade
so,
like
I
do
know
what
I'm
getting
myself
into
in
this
one,
and
I
really
would
appreciate
like
enough
people
in
the
working
group
like
helping
out
with
a
bunch
of
things.
So
what
I've
done
is
like
kind
of
gone
through
all
the
documents.
G
I've
read
like
pretty
much
all
the
documents
that
are
relevant
to
this,
like
already
so
either
like
during
my
id
term
or
after,
like
out
of
interest
and
and
also
I
managed
to
go
through,
like
all
the
mails
on
the
six-man
mailing
list,
I'm
not
sure
if
there's
other
stuff
on
the
spring
list,
that
is
not
copied
under
six
man.
So
that's
kind
of
my
next
step
to
do
and
like
some
really
really
interesting
comments.
G
So,
thanks
to
everyone
who
commented
on
the
mailing
list
and
like
very
specifically,
like
you
know,
to
call
out,
like
you
know,
eric's
mail
was
very
useful
and
and
joel's
mail
starting
off
this
whole
thing
right,
like
you
know,
with
some
thoughts
on
it
as
well
as
brian's
mails.
I
found
them
like
extremely
useful
to
kind
of
clarify
the
issues
in
there,
so
I
just
started
putting
together
a
grab
bag
of
things
that
I
think
should
be
in
this
draft
again.
This
is
like
a
straw
man
proposal.
G
It's
an
individual
wrap
right,
so
I'm
just
like
throwing
this
up
at
this
point
and
if
you
feel
and
there's
something
that
shouldn't
be
in
this
draft
or
something
that
should
be
there,
that
I'm
missing,
please,
like
you
know,
send
a
note
to
me
and
absolutely
like
either
on
list
or
off
list.
Either
way
is
fine
and
we
can
talk
about
like
you
know
what
goes
in
there.
G
So
the
the
key
things
I
want
to
cover
is
like
you
know
how
do
sits,
deviate
from
classic
40
to
91
addresses
right
because
they
don't,
like
you
know
it
kind
of
doesn't
walk
like
a
duck
or
talk
like
a
dog,
but
it
looks
similarly
similar
to
a
duck,
and
so
how
do
we
deviate
them?
G
So
try
to
describe
like
you
know
how
they
act
differently
and
and
like
some
of
these,
have
like
in
a
pretty
clear
answer,
some
of
them
don't
so
I'm
just
throwing
them
all
up
like
because
the
idea
is
to
put
them
in
the
draft
and
to
describe
like
you
know
where
the
sits
are
assigned.
Are
they
assigned
to
an
interface?
Are
they
assigned
to
a
node,
because
it
makes
a
big
difference,
like
other
addresses
that
shows
up
in
sids?
G
Are
they
going
to
be
used
for
neighbor
discovery
or
not
again,
big
difference
like
in
how
and
they
should
be
treated?
And
how
do
they
appear
to
know
that
our
s
are
unaware,
because
I
think
one
of
the
key
differences
for
srv6
is,
like
you
know
the
if
somebody's
unaware
they
treat
us
like
regular,
v6,
packets
right
and
like
is
there,
like?
You
know
any
issues
like
lurking
in
there
that
we
need
to
do,
and
this
is
another
thing
that
came
up.
I
think
this
is
like
a
lot
of
these.
G
Things
have
been
kind
of
like
knocking
around
for
a
while,
and
this,
like
said,
can
it
appear
in
the
source
address
field?
That's
like
something
that
like
is
kind
of
newer,
that
appeared
in
the
picture,
and
how
do
we
do
error
handling?
G
This
is
like
something,
a
topic
that
we
kind
of
addressed
like
earlier
right
when
we
had
like
header
insertion
as
an
option
for
srh,
and
one
of
the
issues
was
that
if
somebody
is
doing
header
insertion
in
the
middle
of
the
network,
how
would
like
a
node
that
doesn't
know
about
it?
Be
able
to
correlate
like
an
error
packet
to
something
it
sent
so
like
vc
says
like?
G
Is
there
like
a
similar
issue
that
we
need
to
handle
right
like
how
would
it
work
for
a
node
to
identify
a
packet
that
caused
an
error
that
came
from
the
network
right?
G
So
so,
if
like
we
decide
to
go
and
do
some
kind
of
separation
in
the
other
space,
like
you
know
where
it's
not
like
the
first
three
bits
like
zero
kind
of
thing
right,
like
you
know,
to
see
if
we
can
like
separate
out
these
things
on
another
space,
where
the
the
semantics
are
expected
to
be
different,
so
this
is
again
something
to
explore.
G
G
So
if
you
have
any
questions
about
these
or
you
think,
like
I'm
barking
up
the
wrong
trees
or
anything
just
like
send,
send
us
a
note
and
we'll
go
from
there
and,
like
I
started
getting
a
few
requests
to
co-author
two,
like
you
know,
I'll
keep
you
updated
that
my
goal
is
to
kind
of
have
draft
out
like
before,
like
end
of
this
year,
like
you
know
some
sometime
like
second
half
of
december,
to
have
like
a
zero
zero
version
of
the
draft
out
and
put
it
up
for
comment
from
the
working
group.
G
So
again,
thank
you
very
much
for
being
patient
with
me,
I'm
asking
for
it
in
advance,
so
please
feel
free
to
send
your
comments.
Thank
you.
C
Thank
you,
suresh,
and
also
thank
you
to
everyone
who
helped
all
of
us
understand
what
it
was
that
we
needed
to
understand
in
such
a
speedy
time.
There
were
lots
of
meetings
with
lots
of
people
explaining
things
and
handling
questions.
There
were
lots
of
documents
circulating
and
people
making
comments
and
generally
helping
helping
us
get
to
some
clarity
on
what
the
core
issues
were.
So
thank
you
to
everyone
who
helped
participate
in
that
process.
C
H
I
Sorry
repeat
that
I
think
the
first
part
clipped.
Would
you
like
comments
on
the
six
man
list
privately
on
spring
list,
on
both.
G
Personally,
the
first
two
run
but
like
I'll
also
start
like
you
know,
following
string
more
closer
because
I
I
do
follow
six
man
all
the
time
and
spring
like
kind
of
on
a
item-based
thing,
but
I
think
that's
gonna
change,
but
I
do
prefer,
like
you
know,
six
man
and
personally
first,
but
like
no
worries
like
if
you
send
it
on
spring
too.
That's
fine!
B
Thank
you
and,
and
then
up
to
people
joining
in
the
microphone
queue
it
looks
like
mitiko
has
a
little
problem
with
a
delay
when
so
unmute
yourself
wait,
counsel
only
two
three
and
then
you
can
speak
thanks
a
lot
guys
thanks
eric
and
suresh
and
now
giuseppe
you're
up.
Do
you
want
to
try
sharing
the
slides
yourself?
Then
you
have
full
control
hello.
Yes,
can
you
hear
me
we
can
hear.
J
K
Yeah,
as
also
bob
and
all
anticipate
that
this
is
an
update
about
the
this
graph.
H
K
Is
in
isg
evaluation
phase,
but
we
did
some
changes
in
the
last
month,
so
it's
better
to
give
an
update
to
the
group.
It's
about
the
pv6
application
of
the
alternate
marking
method.
So
in
this
slide
we
just
summarize
for
who
is
not
familiar
with
this
graph.
So
this
is
a
definition.
Basically,
the
definition
of
a
new
tlv
to
be
encoded
in
the
options
adder,
so
it
can
be
bought
and
up
by
up
options
or
distribution
options.
K
The
format
the
pattern
of
the
tlv
is
in
the
figure,
so
the
first
three
bits
of
the
type
field
are
all
zero.
This
means
skip,
if
you
don't
recognize
and
data
do
not
change
in
root
based
on
the
rfc8200
and
then,
regarding
the
value
here
we
have
the
two
marking
fields
that
are
the
relevant
bits
for
the
alternate
marking,
so
loss
and
delay
bits
and
then
the
flow
monitor
identification
field.
K
K
First
of
all,
I
would
like
to
mention
a
news
that
the
section
on
controller
domain
has
been
improved
in
order
to
explain
better
the
precondition
for
alternate
marking
application
in
a
controller
domain,
then
a
new
subsection
to
clarify
the
usage
scenarios
for
the
measurement
domain,
so
we
call
it
ultimate
marking
measurement
domain.
K
Also,
we
further
specify
the
flow
monitoring
identification
field
that
must
be
used
in
combination
with
source
and
destination
address.
In
order
to
to
avoid
this
amigo
to
solve
this
ambiguity,
and
then
we
also
revised
and
improved
the
security
section
that
now,
I
think,
is
quite
complete.
So
now
I'm
going
to
describe
each
of
these
changes.
So,
regarding
the
controller
domain,
we
clarify,
with
a
must
condition
that
the
alternate
marking
method
must
be
deployed
in
a
controller
domain.
This
means
that
it's
recommended
that
an
implementation
need
to
filter
packets.
K
Entering
or
leaving
the
controller
domain
with
the
ultimate
marking
data,
this
also
solved
many
security
concerns
that
were
raised.
K
K
K
K
Another
clarification
that
we
have
done
in
the
latest
version
is
about
the
the
flow
monitoring
identification
field.
K
We
clarified
that
this
must
only
be
used
for
floyd
intimidification
purpose
for
the
measurement
domain,
of
course,
and
also
it
is
recommended
considering
the
chance
of
collision
of
this
field,
it
is
recommended
that
this
identification
field
is
is
used
in
combination
with
source
and
destination
address
to
identify
flow.
K
So
this
is
this
can
be
acceptable,
but
only
if
we
consider
source
destination
address
in
combination
with
the
flow
monitor
identification
in
case
of
centralized
control.
Of
course,
the
things
are
much
better
because
with
20
bits,
the
number
of
combinations
is
more
than
one
million,
and
in
this
case,
if
you
use
it
in
combination
with
source
and
destination
address,
you
can
monitor
one
million
flows
per
space,
but
I
think
this
can
cover
most
of
the
use
cases.
K
K
K
In
addition,
we
also
clarify
that
for
specific
deployment
scenarios,
multiple
administrative
domains
may
be
traversed,
but
in
this
case,
if
we
want
to
to
have
a
world
controller
domain,
we
have
to
use
ipsec
or
some
vpns
to
secure
the
inter
domain
links
in
order
to
build
the
world
controller
domain.
This
is
also
another
point
that
has
been
specified.
K
Of
course,
the
flow
monitor
identification
is
a
sensitive
information
if
it
goes
outside
the
controller
domain,
but
the
controller
domain
application,
of
course
helped
to
solve,
or
at
least
mitigate
this
issue
as
well
yeah.
The
summary,
so
I
think
that
most
of
the
the
concerns
are
addressed
in
the
latest
version,
so
maybe
some
needs
is
still
missing.
I
don't
know
the
the
latest
spending
point
that
is
relevant
is
about
the
informative
reference
to
experimental,
rfc,
321
and
8889.
K
K
So,
let's
see
if
this
is,
is
a
blocking
a
blocking
issue
to
progress
this
document,
so
we
are
waiting
for
the
next
sg
review
in
order
to
understand
if
some
discussed
positions
can
be
solved
or
not
or
if
we
really
need
to
this
this
document
to
to
overcome
this
issue.
So
that's
all
for
me.
So
if
you
have
questions
comments
and
thank
you.
B
Thank
you
guys
happy.
It
sounds
like
we
there's
enough
hurdles,
but
at
least
we're
making
progress
and
and
we'll
we'll
follow
up
on
the
on
the
discussions.
Let's
hope
we
can.
We
can
sort
those
out
any
comments.
B
Let's
see
so,
where
are
we
now
so
now
we
have
a
set
of
new
individual
internet
drafts.
The
first
one
is
carrying
vtn
identifier
g
dong.
Please
go
ahead,
grant
you
access.
A
L
L
Okay,
here
are
some
background
information.
I
will
go
through
it
briefly.
Basically,
we
are
proposing
to
produce
an
enhanced
vaping
service
to
meet
the
customers,
requirements
in
the
5g
and
other
network
scenarios
which
require
connectivity
services
with
advanced
characteristics,
and
for
this
we
introduced
the
concept
called
vtn,
which
is
a
virtual
underlying
network
consisting
of
a
set
of
dedicated
or
shared
net
resources
and
is
associated
with
a
customized
topology.
L
L
Here
is
the
proposed
new
option
type
to
carry
the
vtn
item,
identifier
and
information
in
the
hubba
hub
extension
header.
Basically,
it
contains
a
for
octet
identifier,
which
is
used
to
uniquely
identify
the
set
of
network
resources
allocated
to
the
vtn,
and
its
lens
is
to
match,
with
the
network
slice
identifier
defined
in
the
3gbp
for
5g.
L
Here
are
the
procedures
to
process
this
information
on
the
a
edge
node
and
the
transient
nodes
on
the
ingress
node.
It
is
based
on
the
classification
and
mapping
policy
of
the
operator.
It
will
determine
how
the
mac
packet
should
be
mapped
to
a
vtn
and
to
encapsulate
outer
ipv6
header
to
get
rid
of
the
waiting
option
in
the
hubba
hub
header,
which
contains
the
identifier
of
the
vtn
resource,
and
the
package
is
mapped
to
then
on
each
node
along
the
packet
path.
L
L
L
L
The
second
comment
was
received
is
to
suggest
to
add
some
text
about
the
relationship
between
the
vtn
and
the
topology
control
mechanisms,
so
that
we
have
this
drought
with
some
text
to
describe
the
mechanisms
used
to
specify
the
writing
topology.
L
L
So
for
the
next
steps,
because
we
think
this
document
proposed
to
you
the
hardware
hub
as
a
extension
header
to
carry
a
new
option
type
for
the
hub
forwarding
treatment
and
which
is,
I
believe,
is
a
suitable
approach
for
this
applica
application
scenario
and
based
on
recent
discussion
and
revisions,
the
content
of
the
document
has
been
stable.
So
the
authors
would
like
to
request
the
working
group
adoption
on
this
document.
B
B
B
M
Okay,
thank
you,
hello.
Everyone!
It's
xiaomi
speaking!
This
presentation
is
on
icmp
v6
echo
request
reply
for
enabled
nc
to
oem
capabilities.
M
B
M
B
Is
there
anything
your
audio
is
clipping
quite
a
lot.
Is
there
anything
you
could
do
to
remedy
that?
You
think.
Oh.
M
I
don't
know
what
well
what's
what's
the
issue,
but.
B
B
B
That's
fine,
okay,
okay,
yeah
yeah,
let's
let's
retry
and
then
we'll
jump
to
the
next
and
come
back
to
you.
Thank
you.
Okay,.
B
Okay,
so
what's
the
link
go,
do
you
have
your
slides
ready
and
then
we
can.
J
J
Excellent:
go
ahead:
okay,
okay,
fine!
We
have
a
middle
size
update
from
from
the
last
presentation,
but
the
last
presentation
was
extremely
short
because
it
was
late
for
the
reason.
Probably
this
time
I
will
speak
like
its
first
time,
because
it's
it's
really
probably
really
the
case.
J
Okay,
the
background
is
probably
very
similar,
which
was
already
discussed
many
times
since
explain
it's
about
flash
numbering,
because
the
primarily
the
use
cases
are
taken
from
flash
numbering,
which
is
already
rfc
from
v6
ops
to
solve
the
problem.
But
there
is
one
big
difference:
there
big
difference
that
we
did
try
to
address
here,
not
just
the
cases
which
has
been
discussed
in
flash
genomic,
but
additionally
multi-hop
multi-prefix,
because
in
the
situation
that
we
have
multi-hop
multi
prefix,
we
have
even
bigger
challenge
for
for
a
situation.
J
When
flash
numbering
will
happen,
then
some
prefix
will
change
and
if
we
have
a
problem
even
for
the
case,
then
the
prefix
will
not
change,
but
even
in
in
the
stable
multi-hope
multi-prefix
environment.
We
have.
We
have
a
problem
and
we
have
found
ways
how
to
address
just
maybe
one
disclaimer
that
we
did
not
drive
to
solve
anything
after
first
hope
I
mean
here.
We
discuss
only
navy
discovery
protocol,
of
course,
for
proper
operation
of
multi-hop
multi
prefix.
You
need
you
need
more.
J
J
Okay,
this
slide,
I
will
tell
I
will
tell
very
short
because
it's
original
problem
which
has
been
brought
to
this
exops
to
six
men
initially
and
each
which
is
discussed
in
89
78,
it's
the
situation,
then
the
router
will
reload
or
the
uplink
will
will
be
established
to
telco
and
after
this,
if
it
would
be
new
prefix
and
if
the
router
will
coincide
with
this
will
be
different
from
the
switch
separate
device.
J
Then
it
may
be
that
the
previous
prefix
will
not
properly
will
not
be
properly
deprecated,
but
the
new
one
will
be
announced
and,
of
course,
host
could
use
both
and
if
host
will
use
old
one
which
is
not
available
anymore.
Of
course
it
will
create
a
problem.
It's
it's
well
known
problem,
which
I
probably
don't
need
to
stress
too
much,
maybe
a
little
bit
new
thing.
J
We
have
here
three
cases,
one
two
three,
because
the
case
number
three
is
really
new
one.
Only
whatever
loba
has
told
us
that
it's
it's
a
new
one
case
from
our
third
author.
It's
a
situation
when,
for
example,
the
box
will
be
disconnected
power
disconnected
and
would
be
replaced
physically
replaced
and
after
reload,
because
it
will
have
different
flash
memory,
different
mac
address
and
it
will
look
like
different
router.
J
It's
a
little
bit
more
complicated
problem,
but
but
it's
okay
could
be
very
similar
to
flash
numbering
the
second
case
again
a
little
bit
discussed,
maybe
not
as
as
much
as
in
this
particular
draft,
but
it's
discussed
already
in
89
78.
That
could
be
the
situation
that
if
some
particular
management
system
will
change
something
up
abruptly
without
proper
duplication,
especially
hard
situation.
J
If
vlan
will
be
changed
on
the
switch,
then
the
host
will
be
connected
to
different
elan,
effectively
different
subnet
and
if
it's
different
subnet,
of
course
prefix
would
be
different
and
the
previous
one
would
not
be
deprecated.
Its
router
in
this
situation
could
do
nothing,
because
if
vlan
will
change
very
fast,
it's
not
possible
to
react.
J
The
situation,
then
some
configuration,
maybe
even
prefix,
would
be
changed
on
the
router
is
possible
too,
but
it's
if
nms
or
sdn
or
whatever,
not
developed
properly.
If
it's
a
really
abrupt
change,
then
again
it
could
change
and
then
the
host
will
have
two
prefixes
and
of
course,
cost
host
could
not
could
choose
the
wrong
one.
J
This
is
a
really
new
slide
compared
to
rfc
8978,
because
here
is
a
discussion
that
could
be
the
situation.
Then
then
particular
site
has
connection,
maybe
by
different
routers
connected
connection.
Maybe
couple
of
connections,
maybe
one
connection
to
different
carriers,
typical
multi-hope
multiplex,
and
in
this
situation
two
things
should
happen
properly.
J
One
thing:
initially:
the
host
should
choose
proper
source
address,
because
if
the
host
will
not
choose
proper
source
address
and
then
it
wouldn't
not
possible
to
reach,
for
example,
wallet
garden
in
one
particular
telco
and
then
after
service
address
properly
chosen,
then
should
be
forwarded
to
to
proper
destination
to
put
to
proper
next.
Initially,
next
scope
should
be
proper
one
on
the
first
hop
link
and
then,
of
course,
it
should
be
proper
one
between
routers,
if
site
has
many
routers.
J
But
this
one
with
one
discussion
about
how
to
do
service
routing
between
within
routers
is
out
of
the
scope.
Here
is
only
the
first
hop
in
the
scope.
These
two
two
stages
to
choose
proper
source
addition
to
choose
proper
next
hope
for
the
host
is
discussed
in
the
in
this
particular
draft.
In
the
two
situation,
in
a
normal
situation,
and
in
this
situation
then
particular
uplink,
for
example,
is
down
it's
it's
a
more
or
less
complicated
discussion.
It's
a
big
section,
a
big
section
in
this
particular
draft
okay
effectively.
J
We
have
here
about
seven
problems
and
for
seven
problems.
We
have
some
number
of
solutions:
nine
overall,
because
some
particular
solutions
is
the
solutions
for,
for
a
few,
for
a
few
cases
effectively,
it's
multi-hop
support
basic
multi-hop
support
for,
from
the
first
hop
point
of
view,
a
situation
when,
in
multi-hop
environment
one
particular
link,
one
particular
router-
is
downed.
Abrupt
configuration
change
is
something
that
change
change,
not
not
gracefully.
If
the
previous
prefix
is
not
deprecated
for
any
reason,
then
some
number
of
reasons
is
discussed.
J
What
it
could
be,
why
why
it
could
not
graceful
could
be.
Of
course,
a
power
outage
could
be
abrupt,
router
outage,
because
you
know
in
in
home
environment
people
typically
try
to
fix
any
problem
by
disconnect
power
reconnect
power.
It's
it's
a
typical
behavior
of
every
subscriber.
J
For
that
reason,
it's
more
or
less
typical
situation
than
home
gateway,
cp,
home
gateway
is
power.
Power,
recycle
is
more
or
less
normal
situation
a
little
bit.
Maybe
small
discussion
on
the
situation
then
link
local
address
of
the
router
itself
is
change
it.
It
may
be
by
configuration
and
there
is
discussion,
what
to
do,
and
there
are
some
number
of
more
or
less
simple,
more
or
less
simple
modifications
which
is
proposed
to
standard.
J
But
okay,
every
modification
is
by
itself
is
maybe
simple,
but
because
overall
is
nine
modifications,
it
overall
may
be
complex
because
maybe
some
permutation,
maybe
some
influence
from
one
particular
modification
to
another.
Almost
all
modifications
related
to
nd
protocol
to
both
drafts,
to
both
rfc
ndn
slack
and
only
only
one
is
related
to
cpu
requirements
where
we
have
recommendation
to
change
current
practice
because
current
practice,
which
is
not
suitable
for
multi-hop,
multi,
multi-perfect
environment,
current
practice,
if
some
particular
uplink
or
some
particular
prefix
route
to
the
carrier
is,
is
lost.
J
Some
particular
prefix
is
lost.
Then
the
current
recommendation
is
to
have
to
to
cancel
default
routers
to
duplicate
default,
routers
status,
but
it's
not
it's
not
possible.
It
does
not
work
properly
for
multi-hop
multi-prefix
environment.
For
that
reason,
we
change
changed
to
recommendation
to
duplicate
prefixes.
It's
not
just
us.
We
we
have
seen
it,
for
example,
from
home
net.
For
example,
they
have
the
same
same
modification
in
reality.
J
Draft
is
more
or
less
big,
because
nine,
nine
nine
solutions
and
for
seven
problems,
seven
technical
problems,
nine
nine
technical
solutions
is
more
or
less
big
big
document.
As
a
result,
we
invite
everybody
for
for
participation
in
discussion
about
this
draft
or
about
we
believe
we
have
found
all
situations,
not
just
flash,
remembering
which
is
already
discussed
in
rfc,
but
we
have
found
all
other
situations,
then
some
particular
nd
protocol
information
could
become
stale
effectively.
It's
like
we
stated
in
the
name.
J
It's
indeed
robustness,
it's
how
to
fix
all
stale
situation
when
information
is
stale
in
ng
protocol.
That's
it
questions.
B
D
Oh,
so
I'm
a
bit
confused
here
because
we
just
discussed
it
on
the
chat
hosts,
which
supports
rule
55
of
default.
Address
collections,
which
is
rfc
1828
right,
will
be
basically
not
really
affected
by,
like
sudden
router
replacement
right.
So
I'm
not
sure
we
really
need
to
tweet.
Indeed,
too
much,
we
already
have
a
solution
for
most
of
those
problems.
It's
just
cost
implementations
do
not
care,
so
maybe
we
need
to
like
focus
on
this
part.
J
We
believe,
no,
that
it's
not
the
case.
Yes
really
1828,
rfc
1828
has
a
good
recommendation,
but
it's
general
without
details
how
to
properly
achieve
this.
For
that
reason,
yes,
this
particular
fc
formally
should
resolve
multi-hope
multi-practice
situation
should,
but
in
reality
it
is
not
resolved,
because
no,
no,
not
enough
utilization.
What
should
be
really
changed
in
nd
protocol?
It's
just
a
good
guidance
good
direction,
not
not
the
detailed
explanation.
What
to
do.
D
No
sorry,
I
think
it's
not
about
changing,
indeed,
protocol,
it's
about
cost.
I
use
a
binding
next
hope
with
the
source
address
right
and
it's
already.
Basically,
it's
basically
rule
55
of
default.
Address
selection.
Unfortunately,
as
there
are
not
so
many
implementations
of
the
hostile
host
side
here,
but
again,
the
chicken
and
egg
problem
hosts
there
is
no
probably
use
cases
yet
for
multi-home
ipv6
networks.
D
J
But
this
host
selection
is
anyway
related
to.
Indeed,
because
you
should
have
you
should
do
two
things
you
should
to
properly
choose
source
address
and
properly
choose
next
scope
to
two
stages.
Rfc
8028
gives
a
general
recommendation
how
to
prop
co.
It's
really
good
recommendation.
We
follow
it
by
the
way
we
don't
contradict
to
this
recommendation.
Just
we
have
more
details,
but
in
reality
we
follow
this
particular
recommendation.
How
to
properly
choose
source
address.
How
much
is
it
enough?
A
Yeah
and
I'll
add
that
my
take
is,
I
think
there
needs
to
be
some
agreement
on
the
problems
before
spending
a
lot
of
time
on
the
possible
solutions
and
see
if
you
can
build
a
consensus
in
the
on
the
list
for
that
there's
some
problems
that
need
to
be
solved
that
we
don't
currently
solve
in
other
mechanisms.
B
I
H
H
That's
right
I'll
even
get
video.
H
This
is
a
new
draft,
it's
a
new
draft,
but
it's
a
very,
very,
very
old
subject,
and
it's
something
that's
been
known
for
about
35
years,
and
the
motivation,
which
is
the
big
picture
for
this
whole
talk,
is
that
some
applications
see
greater
performance
by
sending
ipv6
packets
that
are
larger
than
the
path
mtu.
H
I
have
a
question
mark
after
quick,
because
I
really
haven't
had
time
to
investigate
quick,
but
since
quick
uses
udp,
it
also
could
potentially
see
better
performance
by
using
ipv6
fragmentation
and
then
also
finally
ipv6
tunnels.
Now
this
is
readily
demonstrated
with
iperf
3..
If
you
were
to
put
together
two
ubuntu
laptops
over
an
arbitrary
network
and
use
iperf3
you'll
see
better
performance
by
sending
packets
that
are
larger
than
the
path
mtu
than
you'll
see
by
sending
smaller
packets.
H
Now,
when
a
source
fragments
an
ipv6
packet,
that's
larger
than
the
path
mtu.
We
have
the
problem
that
the
loss
unit,
which
is
an
individual
fragment,
is
smaller
than
the
re-transmission
unit,
the
entire
packet.
So,
for
example,
if
a
64k
byte
packet
was
sent
in
fragments
of
12,
1280
bytes
and
one
of
those
fragments
was
lost,
you'd
have
a
re-transmission
storm
of
64
1280
byte
fragments
when,
when
you
would
really
only
prefer
to
retransmit
just
the
one
that
was
lost.
H
H
H
H
H
So
how
does
the
rrc
8200
ipv6
fragment
header?
Currently
look
it's
as
you
see
here,
it
has
the
reserve
field,
the
fragment,
offset
identification
and
so
forth.
What
this
document
is
asking
is
to
update
rfc
8200
to
remove
the
reserve
field
in
its
place.
Put
an
ordinal
field,
which
is
a
six
bit
ordinal
number
a
reserved
bit
and
an
a
bit
for
arq
supported
and
when
a
is
set
to
one.
The
ordinal
is
going
to
include
code
of
value
between
0
and
63,
which
is
the
ordinal
fragment
number.
H
So
then
we
have
now
this
this.
This
new
icmp
v6
fragmentation
report
message.
The
new
message
is
going
to
include
n
identification,
comma
ordinal
bitmap
list
entries
each
one
of
these
entries
being
12
octets
one.
H
H
If
I
was
zero,
it
means
no
fragment
with
ordinal
fragment
value.
I
was
received
so
that
when
the
source
receives
the
frag
rep,
it
can
retransmit
either
each
per
identification
fragment
where
the
order
bit
bet
nap
of.
I
is
zero
if
the
fragment
is
still
in
its
cache
and
then
the
source.
Finally
discards,
the
frag
graph.
After
all,
those
entries
have
been
processed.
H
So
some
additional
considerations-
the
the
six
bit
ordinal
bitmap,
plus
the
64-bit
bitmap
limits
the
irq
to
only
the
first
64
fragments.
That
means
that
if
there
were
any
additional
fragments
beyond
the
first
64,
that
would
be
sent
best
effort
the
same
as
the
current
practice.
H
H
The
original
source
would
receive
the
soft
error
and
reduce
the
size
of
future
packets,
while
the
original
packet
will
likely
arrive
at
the
final
destination,
so
that
this
is
a
lossless
path,
mtu
discovery,
so
the
icmpb6
packet
to
big
softwares
provide
dynamic
feedback,
so
the
original
source
can
tune
the
packet
sizes,
it's
sending
to
ensure
optimum
performance
with
little
or
no
loss,
lossless
path,
mt
discovery.
H
Well,
each
ipv6
fragment
will
undergo
link
layer
crcs
on
the
path,
as
well
as
transport
layer
checksums
at
the
final
destination
following
reassembly,
so
for
for
pure
ipv6
paths.
This
is
already
probably
enough,
because
ipv6
fragmentation
includes
a
32-bit
identification
number
and
it
also
includes
other
reassembly
safeguards
such
as
non-overlapping
fragments,
but
for
ipv4
paths
or
mixed
ipv6
ipv4
paths.
Ipv4
fragmentation
only
includes
a
16
bit
identification
and
it
has
no
safeguards
against
reassembly
errors
so
that
reassembly
errors
are
possible.
H
H
B
We
could
do
a
poll
of
the
room
to
see
if
there
is
any
interest
in
working
on
this.
H
I'd
just
like
to
reiterate
the
most
important
chart
is
chart
number
two
in
this
deck,
which
gives
the
big
picture,
and
that
big
picture
is
the
fact
that
we're
missing
something
internet
today
and
that's
the
fact
that
we
could
be
leveraging
ip
fragmentation
to
get
better
performance
than
we
can
get
without
it.
H
What's
what
makes
it
faster
is
that
when
you
send
a
large
packet
from
the
application,
you
make
a
single
system
call
and
when
that
packet
hits
the
operating
system
kernel,
the
kernel
then
calls
ip
fragmentation,
which
sends
the
packet
as
a
as
a
series
of
as
a
burst
of
fragments,
and
when
that
burst
occurs,
you
get
very
high
network
utilization.
H
So
it's
that
bursty
nature
of
sending
one
large
packet
and
getting
potentially
as
many
as
64
fragments
in
a
rapid
fire
burst
that
causes
you
to
get
greater
network
utilization
for
that
time
period.
So
it's
a
savings
in
systems,
calls
it's
a
savings
and
interrupts,
and
it's
it's.
It's
making
greater
network
utilization
by
leveraging
these
fragmentation
bursts.
B
So
these
bursts
have
a
tendency
to
be
capped
by
network
devices
in
the
in
in
the
network
too,
but
but
yes,
okay,
so
this
sort
of
some
of
the
problems
that
tso1
hosts
have
tried
to
solve.
I
suppose.
A
Yeah
I
mean
there's
a
well
there's
a
lot
of
discussion
in
the
chat
room,
but
I
mean
there's
also,
I
think,
a
bunch
of
hard
interactions
with
transport
protocols
which
are
also
doing
re-transmissions,
and
it
gets
really
messy
when
you
get.
If
you
had
the
ip
layer
doing
fragment
re-transmissions-
and
you
know
the
transport
protocol
doing
its
own
re-transmissions,
and
I
think
this
is.
H
Bob,
let
me
let
me
stop
you
for
just
a
second.
If
I
could
that's
that's
not
really
correct.
The
the
model
is
rfc
3366,
which
is
link
layer,
irq,
which
is
an
imperfect
but
timely,
retransmission
to
not
interfere
with
the
perfect
and
the
end
retransmissions.
That
might
be
necessary
if
the
fragments
can't
be
replaced.
A
H
Tunnel
endpoint,
the
the
the
the
the
the
original
source
could
be
far
away
from
it
that
that
is
true.
So
eric.
C
Let
me
wait
my
customary
17
seconds
for
video
for
audio
sync
up
as
an
individual
computer.
Sorry,
individual
speaking
as
an
individual
rather
are,
are
some
of
these
things.
Separable,
for
example,
specifically
the
the
ptb
software.
C
Is
there
something
useful
or
valuable
in
just
the
ptp
soft
in
the
softwares
and
possibly
using
that
to
update,
say
a
higher
layer,
tcp
mss
or
something
in
advance
of
it,
discovering
that
it
needs
to
do
mechanization
layers.
H
H
But
this
is
all
discussed
in
detail
in
the
arrow
in
omnidrafts
how
packet2big
softwares
are
used,
and
in
this
case
the
tunnel
endpoint
source
can
send
the
packet
to
big
soft
errors,
but
the
tunnel
endpoint
egress,
could
also
send
packet
to
big
softwares,
for
example,
if
it's
having
reassembly
problems
so
there's
more
there.
Yes,
you're
right
eric
yeah.
C
I'm
wondering
if
it's
it's
separable
into
into
smaller,
yet
still
useful
chunks.
Basically,
thank
you.
I
think
that's
a
good
point.
B
M
Okay,
can
you
hear
me.
M
M
M
M
M
M
Among
them,
a
new
class
number
indicates
iom
change,
tracing
capabilities
object
and
the
c
type
1
indicates
that
pre-allocated
tracing
another
type
of
I
am
tracing
is
incremental
tracing
the
object.
Payload
includes
iom
trace,
type
namespace
id
egress
mtu
and
the
egress
interface
id,
and
one
more
w
bit
is
used
to
indicate
short
format
or
wide
format
of
egress
interface
id
among
them.
The
iom,
trace
type
is
a
bitmap
that
indicates
what
kinds
of
tracing
data
are
supported
by
the
echo
reply.
M
M
The
combination
of
class
number
and
the
c
type
in
the
object
header
indicates
type
of
this
object.
Among
them,
a
new
class
number
indicates
iom
tracing
capabilities
object
and
the
c
type
2
indicates
that
it's
incremental
tracing
the
object.
Payload
of
this
object
is
also
defined
in
that
ippm
document.
M
M
M
M
M
M
M
M
M
N
N
N
Yeah
like
what,
if
I'm
a,
I
am
a
attacker
right,
I'm
a
hacker
and
I
send
a
lot
of
like
ddos
packets,
probably
packets,
to
how
say
to
get
the
iom
information
and
from
your
network.
N
So
I
can
send
thousands
of
packets
to
the
node
and
you
are
seeing
that
you
we
can
use
like
ipsec,
for
example,
or
esp
for
I'll,
say
security.
But
the
thing
is
that
if
you
want
to
provide
this
kind
of
protection,
you
have
provide
a
full
mesh
ip
spec
ipsec
connection
in
your
network.
Is
it
possible
because
you
need
to
ping
any
node
in
your
domain
right.
M
This
job
to
provide
some
security
issues,
mitigation
methods-
you
can
see
in
the
slide,
not
just
yeah,
not
just
use
ip
authentication,
header,
ip,
encapsulating
security,
payload
header.
You
can
also
ask
network
operators
establish
policies
that
restrict
to
access
to
this
functionality.
M
N
Issues
yeah
sure,
and
but
as
you
know,
that
in
the
real
network
the
ipsec
is
really
heavy
or
it's
really
I'll,
say
half
for
implementation
and
usage
right,
it's
very
hard
for
deployment,
and
in
order
to
protect
the
iom
capability,
we
need
to
build
up
full
mesh
any
to
any
ipsec
connection
in
the
network.
I
don't
believe
that
would
be
the
real
deployment
so
that
that
is
my
comment
and
yes,
you
can
like
use
some
rich,
limiting
limitation
method
for
protection
for
protecting
deducts
attack
I'll
go
step.
Yep.
J
I
have
a
question
I
have
not
understood.
Is
it
hope
I
hope
or
end
to
end,
because
I
I
om
typically
is
useful
when
it's
implemented?
Hope
I
hope
then
you
could
understand,
which
particular
hope
is
is
a
problem,
but
it
looks
like
if
it's
icmp,
then
the
packet
could
go
only
end
to
end
and
in
this
situation,
how
much
it
would
be
useful
if
it's
not
hoped
by
hope,
do
you
understand
something
wrong
or
what.
M
Okay,
let
me
explain
in
this
job
to
icmp
icmpv6
echo
request
is
not
just
for
end
to
end.
It
can
be
sent
to
the
iom,
transit
node
along
the
path,
so
every
transiting
node
can
receive
an
icmpv6
like
request
and
the
sender
reply
to
the
iom,
encapsulating
node.
So
that's
also
for
by
hub.
O
C
I'm
curious
to
know
how
large
do
you
think
these
messages
are
going
to
be
and
whether
or
not
you
think
they
might
exceed
the
mtu
of
the
operator
network?
I
don't
know
how
much
information
is
the
complete.
M
M
Yes,
for
the
echo
request,
I
think
the
message
is
it
will
not
be
too
too
big
and
for
the
accurate
reply,
the
message
the
size
of
the
message
may
exceed
the
mtu
limit.
So
in
this
chapter
we
have
a
code
for
the
big
message,
big
mac,
I
could
reply.
I
could
I
could
reply
message
that
exceeds
the
ipv6
mto
limit.
F
M
M
A
A
I
don't
have
personally
don't
have
any
objections
to
more
icmp
messages,
but
it
needs
to
fit
into
a
larger
use
case.
I
think,
but
let's
continue.