►
From YouTube: 6MAN WG Interim Meeting, 2020-03-31
Description
6MAN WG Interim Meeting, 2020-03-31
B
C
C
C
C
C
D
B
B
B
B
B
B
B
B
B
B
B
E
E
E
E
E
E
E
E
E
E
A
A
A
A
A
A
A
F
A
A
G
G
G
H
I
I
I
I
I
I
I
I
B
B
B
B
B
D
D
D
D
D
D
D
A
A
A
I
All
right,
so
these
are
sort
of
virtual
meeting
notes
taken
from
the
rules
that
is,
she
gave
us.
This
is
the
first
of
with
scheduled
two
sessions
idea,
idea
hundred
and
seven
I
will
see
if
there
will
be.
We
have
just
gave
you
one
now,
we'll
see.
You
know
from
the
experience
here
if
there's
interest
in
doing
the
other
one
as
a
virtual
one
as
well
to
get
into
the
microphone
queue
we
just
fit
2
plus
Q
into
the
WebEx
chat
Q.
I
If
you
want
to
remove
yourself
and
that's
the
only
thing
that
the
WebEx
chat,
that
I
use
for
everything
else
goes
into
the
into
the
jabber
room,
I,
don't
think
we
will
do
any
harm
so
consensus
taking
on
the
mailing
list.
Of
course,
we'll
have
discussion
and
bring
all
the
calls
to
the
mailing
list.
After
this
meeting,
I
have
phones
when
you're,
not
speaking,
remember
to
state
your
full
name.
When
you
are
speaking,
the
blue
sheets
go
on
to
the
ether
pad.
I
The
link
is
on
the
presentation,
or
it's
also
on
the
agenda
agenda
in
the
data
tracker,
as
well
as
all
the
materials.
If
you
want
to
see
directly
for
yourself
so
I
think
this
is
the
first
entry
meeting
we
have
in
about
20
years
last,
one
was
in
Grenoble
if
I
remember
correctly,
isn't
that
right
book
if.
A
I
Right
and
so
denote
well
my
place
as
it
always
does
tonight.
If
meetings
we
have
the
jabber
ian,
I
see
not
a
rule.
It's
very
useful
to
be
only
for
this
meeting.
I
think
so.
Please
join
that.
If
you're
able
to
Barbara's
taking
notes
for
us,
Joel
Halpin
is
doing
jabber
scribing
and
the
presentation
link
is
there
and
again
find
the
blue
sheets.
A
A
This
is
in
in
work,
call
we're
hoping
to
get
to
the
point
of
closing,
lit
out
and
there's
also
the
operations
and
maintenance
segment
routing
graph.
That's
also
been
working
with
glance
call,
and
then
we
have
four
individual
graphs,
the
minute
marking
extension
header
graph,
the
transmission
over
multi-link
network
interfaces.
The
credit
is
presenting
improve
robustness,
stateless
sort
of
configuration
by
Fernando
and
then
also
a
problem
statement
regarding
IP
address
usage,
also
by
Fernando.
I
I
I
We
have
two
documents
in
working
group
last
call
both
on
the
agenda
today.
It's
the
privacy,
extensions
document,
RFC
49
this
and
it's
the
OEM
for
same
and
routing
document
I
also
have
two
working
group
documents.
Currently
it's
the
path
into
you
hope,
I
hope
option
which
is
not
on
the
agenda
and
it's
to
be
just
neighbor
discovery,
which
is
movie
agenda.
I
Yes,
I
think
that's
all
from
the
chairs.
It's
just
a
reminder
of
the
new
document
format.
We
have
also
pointers
to
the
d-type
experiment.
We're
running
with
regards
to
like
each
have
experiment.
We
should
even
that's
probably
something
we
can
discuss
a
little
bit
more
on
the
mailing
list.
Now
that
we
have
a
little
bit
more
information
on
it,
so
I
think
the
next
one
in
the
queue
is
Jen.
Do
you
wanna
come
up
and
stand
in
the
pink
box?
Please
I.
G
G
G
Actually,
thanks
for
everyone
who
commented
some
clarification
test
was
added
regarding
a
destination
address
of
such
an
unsolicited,
an
ace.
The
current
proposal
is
to
send
such
an
h2
all
the
routers
multi
customers.
The
reason
is,
first
of
all,
it
would
allow
the
packet
to
reach
all
personally,
because
in
many
scenarios
you
might
have
multiple
routers,
for
example.
First
hope
redundancy
where
P
between
them,
so
routers
host
is
usually
st.
G
Jim
traffic
might
not
be
in
the
routers
return
flow
are
going
through,
so
mark
has
made
my
day
a
very
good
comment,
which
added
to
the
text
that
actually
increasing
the
multicast
level
significantly
by
doing
this,
because
we
basically
making
horse
to
send
one-
is
the
tane
instead
of
a
router
sending
multicast.
In
essence
at
least
multicast
address
to
address
resolution,
the
basically
replacing
one
multicast
break
it
with
another.
G
It's
cutting
potential
disruption.
So
I
spent
some
time
trying
to
look
at
how
the
proposed
mechanism
might
break
something,
especially
in
case
of
optimistic,
a
duplicate
address
detection
because
in
this
case
basically
host
might
start
sending
traffic
and
Salem
canceled
his
tetanus
from
an
address
which
potentially
might
be
a
duplicate
at
one.
Next,
slightly.
G
So,
first
of
all,
if
entry
already
exists
on
a
router
in
any
state,
except
in
complete,
no
changes
right,
it
will
be
unsolicited.
A
neighbor
is
overwrite
a
flux
set
to
zero
Salas
the
flux
set
to
zero,
so
any
existing
entry
will
not
be
updated.
What
happened
if
the
entry
is
an
incomplete
state,
so
it
basically
means
that
there
is
a
rightful
owner
which
is
on
the
network
just
saying
in
return
tracking
just
arrives
and
another
host.
Let's
say:
host
B
join
the
network
and
start
sending
unsolicited
10
days
before
a
dad
has
completed.
G
So
what
happened
normal
right
before
we
implement
the
proposed
mechanism,
so
it
will
statement
draft
explained
we
have
a
kind
of
packet
loss
for
period
between
the
first
packet
arrives
to
the
router
and
the
router
received
solicited
ma
from
a
address
off
next
slide.
Please,
if
we,
if
the
host
wiki
that
address,
starts
engine
cancel
each
the
Tenet's
and
router
updates
neighbor.
Currently
what
happens
during
the
time
new
and
might
be
created
until
the
rightful
owner
responds
to
a
name
like
in
this
case
the
MP
will
be
updated
with
rightful
owner.
G
G
G
G
If
there's
a
rightful
owner,
let's
say,
host
a
which
has
an
address
it
hasn't
been
sending
in
it
received
any
traffic
to
the
router
throughout
them
doesn't
have,
and
it
was
that
address
and
that
host
just
wakes
up
and
starts
engine
condition
in
traffic
exactly
in
the
same
moment
as
another
host
I
came
and
configured
the
same
address
in
optimistic
step.
Next,
like
this,
so
without
unsolicited
a
is
creating
any
entries
on
the
route.
What
happened
here?
Router
sends
multi
customers.
It's
a
basic.
G
If
you
have
two
hosts
with
the
same
address,
one
of
them
in
an
optimistic
state,
both
hosts
will
respond,
and
even
if
the
host
beers
on
the
first
and
it
would
create
a
ritual
entry
in
the
router
as
soon
as
rightful
owner
responds
as
the
entry
will
be
updated
and
because
that
enabled
have
other
overwrite
flag
set
to
one
and
from
that
moment
of
time
the
connectivity
is
restored
all
right.
So
it's
a
normal
behavior
how
it
happens
now
next
slide.
G
G
In
this
case
the
stale
entry
will
be
created
and
if
that
fails
during
the
delay
phase,
because
as
soon
as
packet
received,
the
first
packet
arrived
to
the
rotor
and
routers
trying
to
send
rocket
the
entry
will
move
to
delay
state
because
that
would
normally
detect
the
failure
in
one
second
right.
We
can
expect
that
that
failure
will
happen
during
the
delay.
Spec
right
in
this
case,
the
worst
case
scenario
shot
sent.
Any
customers
would
not
get
any
response
from
host
B.
G
G
Worst-Case
scenario
might
be
the
rightful
owner
might
experience
delay
up
to
eight
seconds
again
if
events
happen.
At
the
same
time,
the
owner
has
been
receiving
any
traffic
through
the
router,
so
there
is
no
cache.
Entry
and
duplicate
address
happened
before
the
traffic
arrives
to
the
route.
By
the
way,
I
have
a
question
to
the
audience.
Do
we
know
if
any
router
implementations
actually
using
the
data
plane
right?
If
you
move
and
tree
frog
delay
to
reachable
next
slightly.
G
Because
in
this
case,
it's
actually
quite
bad
scenario,
probably
if
the
entry
got
into
reachable
stage
that
obviously
the
delay
will
be
much
longer
to
restore
the
connectivity
but
I
have
not
seen
or
outers
actually
doing
this
right.
My
impression
is,
they
do
not
normally
watch
for
data
play
traffic,
so
I'm
not
sure
like.
Is
it
corner
case
bad
enough?
So
we
should
not
be
doing
this.
Oh
it's
way
too
many
things
happening
at
the
same
time.
The
probability
is
quite
low.
I.
G
I
It
seemed
like
a
very
quiet
room,
and
so
we
discussed
this
draft
both
on
a
mailing
list
and
in
the
last
IDF
and
I
think
and
Bob
and
I
have
spoken
about
it
and
I
think
the
plan
was
to
take
this
fairly
quickly
through
the
through
the
working
group.
As
far
as
we
see
it,
we
believe
this
is
ready
for
a
working
group.
G
One
comment:
so
we
have
basically
two
drafts
right,
one.
It's
problem
statement
on
a
which
is
in
v6
hopes
and
another
one.
Is
this
one
so
I
not
sure,
but
I
think
maybe
it
makes
sense
to
have
the
joint
last
call
for
bosses
in
because
honestly,
Fred
it'll
go
for
the
last
call
for
problem
statement,
draft
and
v6
ops
until
we
going
to
the
last
call
with
this
one,
because
let's
say
we
decide
that
this
solution
is
not
good
enough
right.
G
I
I
G
Because,
basically,
let's
take
problem
statement
graph,
discusses
various
approach
to
the
problem.
Right
we
can
Pizza
router
or
we
can
suggest
the
router
should
actually
use
a
data
plane
traffic
to
trigger
neighbor
discovery
for
himself
all
right
if
the
router
she's
a
data
plane
traffic
flow
for
from
the
address
which
it
doesn't
have
a
neighbor
cache
entry
right,
actively
resolution
and
so
on.
So
there
are
various
also
could
be
done.
G
So
I
think
this
should
be
published,
because
it's
explains
why
we
suggest
in
exactly
this
mechanism
and
not
something
else
and
actually
those
drafts
to
so
currently.
At
the
problem
statement
draft
refers
to
this.
One
is
a
normally
from
this.
One
hesitates
a
informative
reference,
because
I
think
it's
simplifies
things
so
the
reference
to
each
other.
Okay,.
J
You
Warren
Kumari
I,
just
want
you
to
reiterate
that
this
problem
was
originally
discussed
at
v6
UPS.
The
issue
was
raised
and
v6
UPS.
The
consensus
seemed
to
me.
Well,
that's
a
real
issue:
let's
try
to
fix
it.
No
actually
it
looks
like
six
man's
the
right
case
to
do
it.
So
you
know
just
six
UPS.
These
except
seems
very
supportive
of
the
problem.
F
I
A
Just
add
one
thing
to
this:
I
mean
there
are
lots
of
funds
in
the
ITF
we're
developing
requirements.
Documents
is
very
useful
to
figure
out
what
we
want
to
do,
but
they
don't
always
get
published.
Sometimes
it's
harder
to
get
consensus
on
a
requirements
document
than
it
is
on
the
actual
and
actual
solution,
but
we
will
certainly
talk
to
the
v6
upstairs
and
throughout
what
they
want
to
do
and
Warren.
I
F
F
One
of
the
issues
that
was
raised
and
was
discussed
on
the
mailing
list
was
about
concerns
about
the
possible
impact
of
using
multiple
addresses
or
many
addresses.
If
you
want
my
sense
of
what
has
been
the
outcome
from
the
working
group
discussion,
this
is
an
issue
that
is
not
specific
of
49-41,
but
it's
a
general
issue
of
slack.
F
Essentially,
slack
is
kind
of
like
anarchy
when
it
comes
to
never
configuration
have
much
control
as
to
you
know
how
many
addresses
each
node
configures,
so
it's
not
really
specific
to
49:41,
but
still
there
was
agreement
that
the
document
should
say
something
about
this.
So,
in
response
to
the
discussions
that
we
had
on
mailing
list,
essentially,
we
did
two
things.
First
of
all,
we
included
specific
text
on
this
stuff
in
Section
four,
the
text
was
circulated
on
the
mailing
list
and
was
agreed
upon
with
the
folks
that
participated
in
the
discussion.
F
At
least
another
thing
that
we
did
was
to
reduce
the
body's
lifetime
value.
That
was
one
month
sorry
one
week,
not
one
month
from
one
week
to
two
days
and
that
effectively
changes
the
number
of
concurrent
temporary
addresses
to
two
from
the
usual
seven
that
you'd
have
with
a
body
lifetime
of
one
week.
Next
slide.
F
G
F
A
number
of
reasons
for
that
one
is,
you
know
the
applications
that
my
one
long-lived
connections
and
fail
don't
last
for
that
long.
It
also
gives
a
mention
about
the
possible
impact
on
network
elements
read
as
the
outcome
from
the
working
group
discussion.
Obviously
not
everyone
agreed
on
this
is
that
it
would
be
about
signal
for
the
ITF
to
to
recommend
disabled
in
a
mechanism
that
is
in
in
some
way
meant
to
improve
privacy
and
in
support
of
this
I
think
we
have
essentially
two
BCPs.
F
First
one
is
on
purpose
in
money
monitoring
and
the
second
one
is
in
is
on
host,
address
availability
recommendations,
which
essentially
already
says
that
God
should
be
alone.
You
know
use
addresses
aside
from
that,
which
is
recommendations
that
even
with
49:41
recommended
temporary
addresses
should
be
disabled
by
default,
all
popular
ip6
host
implementations
that
I
know
of
enable
temporary
addresses
by
default,
so
different
distributions
of
Linux,
OpenBSD,
those
etc
next
slide.
F
And
then
another
one,
this
is
the
last
one.
There
was
some
discussion
about
extent
to
which
temporary
addresses
help
privacy,
49:41
itself
was
called
privacy,
extensions
for
ipv6
slack,
the
discussion
on
the
working
group.
What
I
read
from
that
is
that
temporary
addresses
help
address
base
where
activity
correlation
talking
about
privacy-
probably
impresses
imprecise.
If
you
want
and
I
agree
with
that,
even
I
have
always
thought
myself
that
aim
of
extension
to
call
them
privacy-
extensions-
probably
wasn't
the
best
possible
title.
F
Privacy
addresses
so
also
you
know
limit
the
time
window
during
which
host
is
exposed
be
via
an
address
that
is
exposed,
as
suppose
as
a
result
of
active
communication,
meaning
that
you
know,
if
somebody
knows
your
address
or
how
long
they
can
use
that
address,
to
communicate
with
you,
obviously,
with
temporary
addresses
they
do
have
a
lifetime.
So
you
know
eventually,
even
if
your
address
becomes
known
at
some
point.
It's
not
reusable
anymore.
F
D
F
F
I
Super
Thank
You
Fernando,
so
please
join
the
microphone
queue.
If
you
have
any
comments,
I
think
the
in
a
fundamental
question
here
is,
you
know:
do
people
feel
that
their
last
call
comments
have
been
addressed
sufficiently
and
if
so,
I
believe
this
should
be
ready
to
shape,
will
confirm
that
on
the
mailing
list?
But
you
know
this
is
your
chance
to
to
come
in
and
state.
If,
if
you
don't
believe,
that's
the
case.
H
F
I
F
F
C
addresses,
if
you
want,
but
you
know,
as
I
noted
during
the
presentation.
I
think
it's
better
to
you
know,
try
to
stay
away
from
the
word
privacy,
because
that
means
different
things
for
different
people,
so
I
think
it's
better.
These
temporary
addresses
these
services
do
or
what
this
document
does
is.
You
know
specify
a
mechanism
allows
implementations
to
produce
temporary
address
system
addresses
that
obviously
have
a
limited
lifetime.
F
H
G
H
I
F
No,
assuming
that
different
communications
correspond
to
the
same
system,
if
I
am
changing
the
interface
IDs,
even
if
I
am
the
only
guy
on
the
on
the
subnet,
at
least
the
guy,
you
know
doing
the
neighbor
activity
or
relation
as
to
do
assumptions
that,
in
that
case,
I'm
the
only
fork
on
the
subnet.
So
it's
not
as
trivial
or
asked
by
the
way
as
it
will
be
the
temporary
addresses,
but
anyway,
as
I
said,
I
think
it's
better
to
you
know
talk
about
this
as
worried.
F
Us,
like
you,
know,
specify
some
mechanism
or
producing
temporary
addresses
and,
as
such,
the
consequences
are
this
or
the
implications
are.
These
are
supposed
to
talk
about
privacy
because
still
much
broader
topic.
That's
what
revision
last
revision
0-8
has
tried
to
address
and
if
you
know,
if
I
understood
coming
from
I,
think
that
some
of
the
comments
from
ollie.
I
I
K
K
K
K
We
are
using
a
github
where
we've
been
posting
incremental
changes
and
communicating
on
the
meaning
list.
There
has
been
17
commits
to
the
github
repository
during
this.
We
promoted
them
in
two
different
round.
One
was
version
3
and
then
one
was
version
4
where
we
took
the
last
repository
and
posted
religion,
for
it
has
been
active.
Discussion
of
this
draft
on
the
mailing
list
would
like
to
thank
all
the
folks
that
have
contributed
and
have
provided
comments.
K
So
first
one
is
we
remove
the
TLB
section.
There
were
comments
from
Ron
Bonica,
the
first
male
in
this
list.
The
next
male
is
pointed
to
male
from
Greg,
and
the
third
one
is
appointed
to
me
as
forum
and
then
Queen
and
basically
the
question
was
that
if
the
draft
doesn't
have
a
use
case
illustration
for
TLV,
then
why
do
we
have
this
section
and
authors
agreed
and
we
removed
the
LD
section?
K
The
next
comment
was
regarding
illustration
for
offline
processing.
This
is
like
some
comments
that
were
around
some
clarification
or
the
old
flag
processing.
The
first
in
this
list
is
a
common,
is
a
mail
from
Joel
Harper
and
the
next
one
is
a
discussion
that
happens
with
the
Greek
and
what
we
did
is
we
added
an
illustration
section
or
a
flag
processing
that
essentially
illustrates
and
focuses
on.
Controller-Based
has
a
one
am
use
case.
K
It
is
orchestrated
side
that
we
can
make
it
clear
to
the
reader
on
how
a
flag
is
to
be
used,
and
then
the
next
one
is
the
ICMP
error,
reporting
section.
That
was
a
comment
from
Zen
Queen,
and
the
comment
was
this:
that
if
there
is
no
change
to
the
base
icmpv6,
then
why
is
that?
What
is
the
point
of
reporting
it
in
this
draft?
We
remove
that.
Obviously,
the
draft
relies
on
the
base
ICMP
v6
processing,
as
as
is
without
any
change,
so
there
was
no
need
as
such,
and
this
section
has
been
removed.
K
We
need
some
normative
texts
on
what
happens
when
packet
is
is
given
to
the
one
in
process
and
what
we
did
is
we
added
some
amateur
texts
of
that
nature.
The
rest
of
the
details
are
implementation,
specifics
and
we
point
that
out
as
well
in
the
draft
really
clearly-
and
this
is
how
we
address
these
comments.
K
The
last
row
in
this
table
is
regarding
the
discussion
that
happened
on
the
n
dot.
Otp
said
where
the
reference
is
from
email
conversation
with
your
Harper,
Greg,
menisci
and
and
many
others,
and
the
point
was
this
again-
that
since
the
drug
does
not
have
use
kiss
for
this
specified,
it
is
better
to
move
it
to
a
place
where
the
use
case
would
be
specified.
So
we
removed
the
end
or
OTP
said
as
as
to
add,
read
that
comment
and
next
set
is.
K
So
then,
now
the
next
set
of
comments
are
mostly
for
clarification.
Texts
that
was
needed
and
were
asked
for.
The
first
row
here
is
on
the
scope
of
a
flag
for
passive
onm.
Essentially,
there
was
a
comment
like
how
the
passive
enemy
is,
how
the
flag
is
used,
and
it
was
confusion
of
the
scope
and
also
we
did
clarify
that
all
of
that
the
passive
of
flag
is
used
for
passive
venom
and
that
lead
to
the
next
set
of
question
that
Greg
and
other
has
on
the
mailing
list.
K
K
I
K
K
K
So
we
were
on
the
relationship
between
is
200,
nm
and
and
and
the
classify
MN
by
a
flag
and
passive
when
M
biofloc
is
a
controller
base
when
n,
where
copies
of
the
packet
is
sent
to
a
controller
for
correlation
wariness
to
own
M,
is
a
mechanism
where
the
own
M
data
actually
go
in
the
packet
itself.
So
that
is
the
difference
and
that
that
has
been
very
clearly
clarified.
Both
through
illustration,
as
well
as
through
normal
attacks
or
ordinal
numbers,
gets.
K
There
was
a
clearly
missing
entry
for
I,
any
consideration
for
Oh
flag
registry.
That
was
gladly
added
with
the
draft
next
slide.
Please
and
then
the
next
set
of
questions
are
related
with
editorial
changes.
So
you
are
anderson,
provided
a
very
detailed
review
with
approximately
36
comment.
We
have
addressed
all
of
them
and
those
has
been
act
bylaw.
K
There
were
other
comments
as
well
to
her
address
as
either
clarification,
tax
or
substantial
changes,
but
here
is
that
they
were
additional
comment
that
was
related
with
a
Tori
changes
and
those
are
addressed
and
and
the
same
apply
with
the
comments
that
we
received
from
Ron
Monica
and
they
have
their
words
on
editorial
changing
requested.
Those
changes
had
been
made.
There
was
a
detailed
review
done.
A
min
and
those
detailed
reviews
had
been
responded.
Back
min
has
responded
back
on
the
list
on
one
pending
item
and
that
would
be
addressed
as
well.
K
There
were
two
your
comments
in
great
emails
as
well,
and
those
comments
have
been
addressed.
They
were
any
comments
from
right,
carpenter
as
well
and
those
are
address.
There
are
other
machinist
comments
as
well
from
other
folks
and
and-
and
they
have
been
addressed,
this
list
is
not
exhaustive,
expect
is
so
on.
The
pending
changes,
like
I
mentioned
Lua,
had
detailed
view
with
citizens
coming.
K
So
we
have
I
mean
we
acknowledge
that
these
two
comments
have
been
not
address
and
we
do
plan
to
address
them
very
shortly.
The
bomb
Bob
Hendon
kindly
had
comments
on
the
XML
file
sent
priority
to
the
author,
and
these
are
again
issues
with
the
XML
file.
We
do
acknowledge
that
we
have
not
get
chance
to
address
tone,
but
we
will
address
then
gladly.
The
none
of
this
comment
will
require
any
substantial
or
normative
change
to
the
document.
L
Please
you
said
that
you
had
a
illustrations
of
obit
processing
to
address
my
comment
and
you
added
illustrations,
but
that
doesn't
address
my
basic
problem
with
the
description
of
the
obit
processing.
The
description
describes
something
that
is
entirely
internal
to
the
device
and
does
not
describe
the
actual
behavior
that
must
be
performed.
L
The
description
says
must
make
a
copy
send
to
control
with
a
timestamp.
Well,
that's
not
it's,
not
an
external
observable,
that's
not
something
we
standardized
at
all
the
question
that
you
met.
The
document
needs
to
address
is:
what
does
the
router
actually
have
to
do
with
a
packet
that
has
the
obit
set?
K
L
L
K
L
L
L
K
Also
attacks
on
externally
visible
elements
that
talks
about
a
limit
read
the
copy
of
this
packet,
which
is
externally
visible.
What
is
expected
from
it
and
that
could
complement
it
with
the
illustration
I
think
what
would
be
good
is
if
you
can
have
a
look
on
the
illustration
section
would
be
happy
to
have
another
colleague
as
well
with
you
or
discussion,
to
give
your.
L
Illustrations
that
they
do
not
tell
me
normatively
what
you
expect
the
device
to
do
and
I'm
sorry
Bob
I
understand
that
normally
sent
text
is
the
appropriate
response.
But
when
I
don't
know
what
the
document
is
actually
telling
me
to
do,
I
have
a
problem
and
I
have
a
very
basic
problem.
My
rule
for
this
stuff
is
always
if
this
is
approved
as
an
RFC.
Is
this
something
I
can
implement?
I
do
know
what
to
tell
my
implementers
to
implement
from
this,
but.
K
They
implemented
that
I
will
remember
this
the
distance
formation
so
but
I
mean
this
has
been
implemented.
So
anyways
I
think
the
point
that
is
okay.
We
can
we're
happy
to
talk
with
you
even
set
up
a
WebEx
call
to
come
to
a
tax,
explain
and
then
come
to
an
understanding
of
what
you
are
expecting,
because
what
is
not
clear
to
us
is
what
you
are
expecting
beyond,
above
and
beyond
what
it
is.
In
the
document
we
have
external
behavior.
We
have
internal
Kuroko.
L
I
Is
something
we
have
to
take
to
the
list?
I
mean
if
there
are
other
people
who
you
also
see
Joe's
point
I'm
sure
it
would
be
helpful
if
they
could
also
try
to
express
it.
You
know
differently,
so
we
can
see
so
we
can
get
some
help
figuring
off.
You
know
what's
missing
here
in
the
description
on
the
old
flag,
but
I
think
we
have
to
take
it
to
the
list.
M
Thank
you.
Apologize
I
didn't
get
a
chance
to
read
the
latest
version,
so
I
cannot
say
what
this
I
want
to
make
two
comments.
First,
I
think
that
your
interpretation
of
om
crucification,
they
RFC,
77,
99
and
old
flag
as
a
passive
om,
is
incorrect
because
you
are
using
this
and
you're
modifying
the
packet,
so
it
would
be
a
hybrid
om.
M
Continue
our
discussion
on
what's
the
difference
between
using
old
flag
and
using
IOM
approach
and
I
would
appreciate
to
be
part
of
the
discussion
on
the
topic
that
Jo
brought
up
because
I
do
have
my
concerns
there,
as
well
again
before
their
new
text,
but
I'll
read
the
text
and
now
coming
to
the
list.
So
that's
probably
it.
K
K
The
point
regarding
how
it
is
differ
from
any
of
the
IOM
work,
so
here
the
motivation
is
to
get
this
data
from
only
segment
endpoint,
because
these
are
the
nodes
that
are
well
suited
for
information
of
they're
very
well
suited
points
in
the
network
for
trafficking,
giving
the
other
than
were
burning
Network
with
all
the
information
they
provide
information.
So
so
that
is,
there
is
one
aspect
that
we
can.
B
About,
let
me
make
sure
I
understand
the
mechanism
say
for
a
minute:
you're,
not
pinging,
you're,
just
sending
a
packet
to
a
CID
and
the
packet
reverses
the
IGP
least.
You
just
send
an
ipv6
packet
destination
addresses.
That
said,
there's
no
SRH
involved
at
all.
Now
you
decide
that
you
wanted
to
hang
the
CID
so
would
have
to
include
an
SRH,
so
that'd
be
first.
G
B
K
K
K
So,
essentially,
with
respect
to
the
deployment
implementation
intraoperatively,
there
are
six
known
deployments
of
the
drafts
in
production
occurred
and
there
are
additional
and
disposed
deployment.
Our
implementation
status
as
well,
that
is
noted
in
the
deployment
draft,
which
is
mention,
is
a
source
on
this
page.
So
we
can
have
a
look
and
all
the
deployments
for
this
drug,
because
I
just
talked
about
it.
For
that
word
platform
that
have
shipping
code
with
this.
K
This,
including
including
right
now
in,
will
refer
to
interoperability.
They
were
interrupt
done
at
e
EA
NTC
in
2019,
there
was
as
well
the
multi
vendor
in
shopton
and
NTS
for
Congress
or
showcase.
It
will
cover
M
Congress,
and
there
are
authors
are
aware.
Offs
was
interoperate
retesting
between
vendors.
They
were
privately
done.
K
K
We
will,
as
we
mention
we
will
address
all
the
pending
comments.
The
comment
discussion
that
happened
today
and
like
folks
to
review
revealed
enforce,
send
any
additional
comment
on
the
minimalist
or
you
can
reach
us,
and
one
question
for
the
chairs
is
that
maybe
it's
a
good
opportunity
to
explain
to
the
group
the
expected
unit
of
the
good
hub,
because
that's
what
we
have
been
using,
but
it
would
be
good
to
get
that
clarified,
because
I
think
there
was
some
confusion
during
the
use
of
github,
both
from
authors
as
well
as.
I
I
You
could
have
that
discussion
on
github
as
well,
but
it's
sort
of
discussions
quickly
diverge
from
from
sort
of
the
text
itself,
so
you
know
it
seemed
like
they
would
do
better
on
the
mailing
list,
but
it
has
been
you
know
so
far.
I,
don't
think
we
have
seen
any
pull
requests.
So
it's
early,
you
know,
so
this
is
sort
of
back
to
the
IGF
Montreux
proposed
text.
I
If
you
won't
change
his
proposed
text
and
and
if
you
have
text,
please
do
too
much
pull
requests,
but
but
that's
pretty
much
us
as
far
as
it
goes,
and
it
is
an
experiment,
you're
free
to
propose
text
in
in
the
mailing
list,
with
all
the
new
as
we
have
done.
You're
marking
them
as
all
the
new,
as
we
have
done
in
the
past
as
well.
K
No,
that
sounds
good
to
me.
We've
been,
we
found
that
ahead
of
uploading.
A
word
on
github
for
incremental
changes
is
very
efficient,
so
I
think
that's
from
the
experience.
That
would
be
the
feedback
and
we
continue
to
use
it
and
and
because
it
always
yeah,
this
change
had
been
addressing.
Guitars
I
would
look
at
there
and
then
we
can
promote
a
few
versions.
I
I
Don't
think
we've
quite
gotten
to
that
point
yet,
but
but
at
least
we
sort
of
experimenting
with
the
tool
to
see
if
it
does
help
us
as
a
group
of
people
trying
to
do
some
collaborative
editing
on
a
document
but
we'll
see,
but
takes
a
lot
so
far
for
the
a
chemical
update.
I
think
we
need
a
new
revision
right
that
that's
at
least
at
least
clear,
and
this
finishes
the
working
group
documents.
The
next
one
is
gives
epi
on
the
ipv6
application
of
the
alternates
marking
method.
Let's
say
individual
document
disappear.
Are
you
ready?
I
N
N
Just
to
give
a
quick
recap
about
methodology,
so
maybe
I
don't
know.
Many
people
is
familiar
with
this
methodology,
I
hope
most
of
the
folks.
Anyway,
they
alternate
marking
methodologies,
no
I'm
performance
measurement
technique.
Particular
it
can
be
classified
as
I
breed
or
also
passive,
depending
on
point
of
view.
The
reference
documents,
RFC
8321
and
also
the
duty
point
of
mark
draft
at
ease
in
RFC
editor
q.
N
So
the
basic
idea
is
to
batch
the
packets
by
is
reaching
the
value
of
a
single
bit.
This
way
we
can
group
the
packets
and
count
the
packet
loss
along
the
pot
and,
in
addition
to
packet
loss,
it's
possible
to
measure
also
the
delay,
particularly
in
single
marking
methodology.
We
can
measure
first
and
last
packet.
Delay
of
a
group
of
packets
are
also
average
delay.
If
we
want
more,
informative,
I
can
delay
matrix.
N
N
N
N
The
marking
field
and,
in
the
end
the
best
choice
was
news
of
the
an
option
adder
that
can
be
bought
up
by
up
or
destination,
depending
on
which
kind
of
performance
measurement
we
want
to
enable.
In
summary,
the
alternate
marking
application
is
very
straightforward
and
seemed
very
simple
because
it
does
not
affect
the
packet
behavior,
just
the
source
node.
N
N
We
follow
the
option,
either
format
and
you
can
see
the
red
box,
the
generalized
data
fields,
so
we
had
the
two
marking
fields
the
lost
bit
and
the
delay
bit.
We
had
also
a
flow
monitor
flow
monitoring
identification.
This
is
requirement.
This
is
required
for
some
general
reason
and
deployment
experience.
In
particular,
the
destroy
identification
helps
to
reduce
the
per
node
configurations
or
apps
to
be
reduced.
N
N
Okay,
as
encapsulation
header
option,
we
can,
we
can
have
different
alternatives
that
we
can
evaluate.
For
example,
if
we
use
this
option
address
this
Nisshin
option,
the
measurement
can
be
done
only
by
the
node
in
destination.
Address
I
thought
by
up
option
is
the
best
way,
because
every
route
around
the
path
with
this
feature
enable
can
make
measurement.
N
There
is
also
we
also
mentioned
the
option
of
the
SI
R
htlv,
but
in
this
case
every
node
that
is
a
nap
in
the
yessiree
in
the
SL
path,
can
be
you
can
do
the
measurement
and
the
same
behavior
can
be,
can
be
obtained
with
the
destination
option,
together
with
the
SI
rage
in
this
case,
or
so,
every
node
that
is
an
entity,
can
make
the
measurement
in
any
way
we
clarified.
Also,
after
some
discussion
of
meaningless,
we
clarified
the
usage
of
the
sh
t.
N
N
N
From
the
zero
one
version,
so
we
got
several
comments
on
my
list
from
bobble
Tom
on
drying
and
thank
for
raising
the
discussion.
As
I
said,
these
fruitball
feedbacks
had
to
clarify
better
the
scope
of
our
graph
to
help
to
analyze
how
to
encode
the
TLD
for
alternate
market
application,
also
adjust
the
wording
somewhere
and
updated
references.
N
We
also
added
the
definition
of
three
high
order:
bits
of
the
option
type
in
the
very
last
version
and
a
new
quarter
as
a
joint,
maybe
some
last
conversion
before
I
think
we,
our
next
slide,
will
be
the
last
one
yeah,
the
next
step
that
we
we
think
that
we
are
from
an
agreed
way
to
apply
alternate
marking
and
also
its
extension,
that
is
in
alpha.
Sierra
talked
you
and
the
others
considered
the
draft
ready
for
working
group
adoption.
So
anyway,
we
are
open
to
questions
comments
and.
B
I
B
B
N
Regarding
regarding
your
first
point,
yeah
do
I
write
motor
Fiat,
321
and
multi-point
Altmark
draft
experimental.
There
was
also
some
discussion,
particularly
during
the
ad
review
of
the
multi-point
of
mark
draft
about
the
scope
they
media
suggest
to
change
into
informational,
but
anyway,
experimental
and
informational,
nothing
change.
We
can
consider
borderline
between
experimental
and
informational,
but
anyway,
be.
N
N
We
also
have
a
drafting
beer
that
is
standard
track
because
it
applied
the
RFC
283
21
to
the
beer
to
the
multicast
traffic,
and
it
is
following
the
standard
track,
because
in
that
case,
in
beer
we
are
asking
for
2
bit
to
implement
and
to
encode
the
alternate
marking
application,
and
it
is
basically
the
same
thing
that
trying
to
do
with
ipv6.
So
we
aims
to
define,
beats
and
also
we
have
defined
generalized
to
encode
the
alternate
marking
application
and
to
make
it
in
order
to
go
beyond
the
experimental.
N
O
N
It's
what
completed
from
all
the
point
of
view,
because
it
investigated
all
the
expect
of
the
deployability
of
these
methodologies.
But
the
only
things
that
we
need
to
deploy
is
the
space
in
the
packet
header.
Otherwise
we
cannot.
We
cannot
deploy
this
methodology,
there
are
already
experimental
deployments,
but
in
telecom
italia
network
and
also
as
a
product.
That's
another
product
presented
that
are
already
deployed,
but
anyway,
to
make
it
applicable
and
standard.
We
need
to
follow
the
standards
track,
in
my
opinion,
in
order
to
really
define
the
field
that
apply
this
method.
I
E
You
late,
it
is
Eric
back
here
without
any
head
here.
First
Tuesday
P!
Thank
you
so
much
for
the
document.
As
a
side.
Note
I
really
wonder
whether
it's
really
not
a
waste
to
spend
a
complete
extension
header
just
to
con
transport
to
bits,
but,
okay,
so
I
depart
I
really
want
the.
My
real
question
is
about
using
the
hop-by-hop
extension
header,
in
this
case,
typically
measurement.
E
My
understanding
are
done
and
to
end,
and
in
order,
if
you
are
using
hop-by-hop,
it
means
that,
if
you're
out
on
the
path
we
like
to
have
a
huge
amount
of
credibility
issue,
because
it
needs
to
remember
all
those
measurements
compared
to
the
end-to-end
and
I'm
pretty
sure
as
well,
that
you
know
that
hope,
I
hope
expression,
others
are
still
quite
drop
a
lot
over
the
Internet.
This
fishnet
there
it's
a
little
bit
better
on
this.
N
Yeah
I
I
know
that
I
buy
up
options
is
not
is
not,
we
can
say
recommended,
but
in
order
to
see
a
ATT
thousand
two
hundred,
it
is
also
stated
that
in
case
there
is
a
strong
motivation
or
the
user
job
of
IAP
it
can
be
defined.
But
a
part
of
that
you
can
consider
that
the
hope
by
the
intermediate
nodes
don't
need
to
need
to
read.
H
N
Option
option
either,
and
so
they
don't
need
to
handle
or
modify
the
content
of
the
option
either.
So
maybe
this
can
be
easily
managed
by
Browder
instead
of
other
kind
of
option
either.
When
you
have
to
put
information
in
this
case,
you
just
need
to
read
the
marking
that
is
set
by
the
source
node.
So
these.
E
E
O
Thank
you,
their
client,
no
hats
sort
of
similar
to
Eric's
comment.
Actually
I
was
wondering
with
respect
to
hop
by
hop
or
how
about
versus
destination
option,
whether
or
not
there
was
value
in
having
both
that
you
might
use
destination
for
sort
of
just
end-to-end
measurements,
and
you
might,
if
you
say,
wanted
to
do
something
across
across
your
own
networks.
If
you
were
running
a
multi,
continent-wide
backbone
network,
and
you
wanted
to
try
out
some
stuff,
you
could
use
the
hop
by
hop
options.
O
N
It's
correct
because
the
scope
of
the
draft
is
to
define
the
general
TLV,
the
general
option
that
can
be
included,
but
as
of
May
up
and
also
with
destination,
option,
of
course,
and
also
I
also
mentioned
the
case
of
V.
But
it
will
be
in
the
future
if
it
will
be
used.
But
for
now
we
can
focus
on
bottle
by
up
and
nation
option.
O
N
Idea
is
to
to
leave
the
choice
to
the
implementers,
maybe
better,
maybe
also
if
the
draft
will
be
adopted.
We
can
continue
the
analysis
and
together
with
working
group,
to
understand
what
are
the
limitations
for
each
kind
of
deployment
and
so
on.
So
that
is
the
idea
for
now
to
leave
both
options
open
for
deployment
ation
and
then
we'll
see,
yeah.
D
D
So
in
terms
of
agenda
for
this
talk,
I'm
going
to
get
some
background
in
motivation.
The
mobile
node
mobility
service
architecture
model,
the
Omni
her
face
model
is
off
I'll,
be
discussing
about
the
maximum
transmission
unit.
Link-Local
addresses
a
new
option
called
the
Omni
on
router
discovery,
registration,
a
conceptual,
a
multi-link
selection,
algorithm
and
then
state
document.
The
next.
D
Okay
background:
the
international
civil
aviation
organization
is
designing
a
worldwide
ipv6
based
aeronautical
telecommunications
network
within
in
protocol
services.
It's
going
to
be
known.
The
18th
IPS
each
aircraft,
mobile
node,
is
assigned
a
unique
mobile
network
prefix
from
an
aggregated
mobility
service
prefixed
by
the
mobility
surface
service.
Prefix
Authority,
for
example,
like
a
would
be
the
authority
for
the
mobility
service
prefix
for
the
ATN
IPS.
D
So
if
the
MSP
is
a
slash,
32
then
slash
56,
M
NPS
can
be
assigned,
and
then
the
aircraft
acts
as
a
mobile
ipv6
network
aircraft
that
connect
to
the
ATN
IPS
would
be
a
multiple
air-to-ground
wireless
data
links
and
these
data
links
off
and
have
diverse
properties.
Some
examples
are
video
mode.
Eleda
axis
sack
arrow
Max
and
there
will
be
others,
so
we
need
an
air-to-ground
interface
for
multi-link
coordination
and
that's
what
this
document
is
about
and
again
document
is
titled
transmission
of
ipv6
packets.
D
Over
overlay,
multi-link
network
interfaces,
we've
received
receive
substantial
review
input
both
from
the
ICAO
working
groups
and
from
my
ATF
members
and
they've
resulted
in
significant
improvements
and
the
dip
Draft
has
been
reissued
with
alignment
to
the
six-man
working
group
and
members
of
the
ICAO
communications
panel.
Working
group
by
mobility
subgroup
have
issued
a
for
action
liaison
statement
on
329
requesting
standard
attack
publication
next
chart.
Please.
D
So
on
the
right
again,
you
see
a
block
of
the
of
a
mobile
node
in
the
upper
portion
of
the
diagram,
and
it
has
multiple
access
network
linked
connections
over
those
access
network
link
connections,
the
mobile
node
sends
native
ipv6
packets
and
they
are
received
by
an
access
router
that
connects
that
access
network
to
the
rest
of
the
global
worldwide
aeronautical
telecommunications
network.
So
you
have
native
ipv6
packets
on
the
access
network
interfaces.
D
Okay,
let's
go
to
the
next
chart
and
what
I
want
to
do
now
is
to
look
more
detail
at
the
architecture
of
this
mobile
node
that
we
had
in
the
previous
diagram.
The
mobile
node
has
a
virtual
interface
known
as
the
omni
interface
and
that's
the
nodes.
Virtual
interface
connection
can
configure
it
over
multiple,
diverse,
underlying
a
net
error
phases.
D
So
the
again
there
would
be
SATCOM
el
Dax
aeramax
would
be
examples
of
these.
These
interfaces,
the
omni
interface
of
science
and
v6
link
local
address
known
as
the
omni
link,
local
address
and
that's
used
for
neighbors
messaging
and
the
access
network
interfaces
are
an
unnumbered
interfaces
underneath
the
the
the
omni
interface.
So
there's
no
IP
address
assigned
to
the
connected
access
network
at
the
interfaces
in
the
omni
interface.
The
moment
owns
logical
attachment
to
what's
known
as
the
Omni
link,
which
preserves
the
non-broadcast
modal
axis
link
model.
D
D
Maximum
transmission
unit,
we
are
saying
that
the
Omni
interface
maximum
transmission
unit
is
90
180
bytes.
That
number
came
for
RC
2492,
but
there
was
a
strain
of
earlier
RFC's
with
that
number
was
motivated
from
and
that's
the
number
that
we're
gonna
be
using
from
the
Omni
in
her
face.
So
only
the
Omni
interface
MT
is
exposed
to
the
ipv6
layer,
while
the
underlying
aim
interfaces
may
have
a
wide
variety
of
diverse
em
to
use
that
could
be
smaller
than
90
180.
For
example,
1280
1400,
1500
cetera
the
traditional
approach.
D
When,
when
an
ipv6
packet
comes
into
the
omni
interface,
it
would
drop
the
packet
that
was
too
large
for
not
selected
underlying
interface
and
returning
the
internally
generated
packet
too
big.
But
we
want
to
do
better
than
that.
So
we
have
a
new
approach
where,
within
the
omni
interface
will
perform
link-local
RFC,
24,
73,
encapsulation,
ipv6
and
ipv6
encapsulation
then
apply
a
p6
fragmentation
to
the
aina,
an
interface
MTU
size.
The
link
local
destination
then
gets
to
reassembly
and
it
can
optionally
return
advisory
packet
to
bags
if
reassembly
becomes
problematic.
D
This
provides
us
with
lossless
path.
Mtu
discovery
the
source
is
going
to
dynamically,
adjust
to
any
Advisory
packet
to
big
messages
with
no
loss,
and
it
supports
sizes
up
to
9
kb
jet
Gigabit
Ethernet
jumbo
frames
across
any
access
network
link
type.
So
the
number
of
9180
is
not
the
size
of
the
physical
data
link
units,
underneath
what
it
is
is
the
size
that
the
receiver
needs
to
be
able
to
reassemble
next
chart.
Please.
D
The
mobility
service
assigns
link
local
addresses
from
the
prefix
fe80
/
96,
so
those
addresses
would
be
fe80,
colon,
colon,
1,
2,
3,
etc.
Up
to
Fe
F
F
F
F
F
F,
the
ipv6
link
local
subnet
router
anycast
address
is
already
defined
in
RFC.
42
91
is
fe80
colon
colon,
so
that's
that's
used
as
defined
in
RFC
1491,
and
we
reserved
a
block
of
future
use
of
dresses,
fe80
:
F
F
F
F
F
through
all
apps.
D
So
this
is
under
the
assumption
of
the
/
64
prefix
length,
the
ipv6
addressing
architecture
changes
to
permit
future
prefix
lengths
of
65
or
longer
the
Omni
link.
Local
address
format
is
going
to
be
able
to
accommodate
up
to
/
118,
so
that
provides
a
speech
proofing
in
case
we
get
to
the
point
where
we
have
prefixes
longer
/
64
chart.
Please.
D
Now
the
Omni
interface
is
going
to
be
using
a
new
ipv6
neighbor
discovery,
option
type
called
the
Omni
option.
It's
going
to
appear
on
ipv6,
neighbor,
discovery
messages.
We
need
a
new
type
defined
by
Jana
Jana
and
the
Omni
option.
Header
includes
a
prefix
length
and
our
flag
to
be
used
for
source
address,
based
prefix
registration,
so,
for
example,
in
an
RS
message,
if
the
source
address
was
fe80,
Quang
Quang,
2001,
DB
a12
again,
this
would
be
a
an
omni
link
local
address.
D
If
the
prefix
length
was
56
and
our
want
one
meaning
to
register,
then
the
mobility
service
will
register
the
mobile
mobile
network,
prefix
2001
DB,
8,
1,
2,
/
56
in
the
routing
system.
You
can
think
of
this
as
a
stripped
down
version
of
delegation,
because
all
we're
trying
to
do
is
register
the
prefix
in
the
routing
system.
Since
the
mobile
node
already
knows
it's
prefix.
All
it's
asking
to
do
is
for
the
mobile
mobility
service
to
register
the
prefix
in
the
routing
system
and
then
within
beyond
the
option.
D
There
is
a
list
of
sub
options
that
follows
that
has
multi-link
and
mobility
service
parameters,
and
you
can
see
below
the
format
of
the
sub
options
and
the
currently
defined
sub
options
that
we
have
pad
one
pad
in
life
index,
two
bolts
of
two
different
types:
mobility,
service
register
and
mobility
service
release
next
chart.
Please.
D
So
the
option
includes
what
we
call
if'
index
tuples
and
there's
type
1
and
type
2
IFM.
Next
tuples.
Both
types
include
an
if'
index
that
identifies
the
underlying
access
network
interface
and
I
have
type
which
is
the
type
of
the
I
in
that
interface
very
similar
to
the
way
I
FNX
knife
type
are
used
in
in
network
management
provider.
Id
is
set
to
the
access
network
service
provider,
and
then
we
have
a
link
quality
metric
with
one
being
the
lowest
15
be
in
the
highest.
D
Zero
means
that
the
link
is
down
type
1
s,
tuples
include
a
vector
of
two-bit
preference
values,
preference
values
0
through
63
correspond
to
the
64
IP
differentiated
service
code
points,
P,
64
and
above
our
additional
traffic
selectors.
They
could
be
based
on
application,
port
numbers,
IP
address
ranges,
etc,
and
each
p
value
includes
a
two-bit
value,
3
to
1,
meaning
high
medium
or
lower
disabled.
D
D
So
then
router
discovery
prefix
registration
using
the
Omni
interface.
What
happens
is
that
the
mobile
node
will
send
router
solicitation
messages
with
omni
options
and
they'll
be
sent
over
individual
a
net
interfaces
that
are
configured
underneath
the
omni
interface
when
the
access
router
receives
the
router
solicitation,
it
notices
the
omni
option
and
then
coordinates
with
the
mobility
service.
The
axis
router
then
returns
router
advertisements
with
the
omni
option
and
any
auto
configuration
information
that
would
normally
delivered
be
delivered
in
a
solicited
router
advertisement
message.
D
So
what
the
mobile
node
does
is
sends
initial
router
solicitations
to
register
its
mobile
network
prefix
and
an
initial
set
of
up
a
net
interfaces.
So,
for
example,
if
needing
it,
video
mode
2
is
up.
You
send
a
router
solicitation
over
the
via
de
element
2.
If
the
SATCOM
is
up,
you
send
a
router
solicitation
message
over
the
route,
the
the
SATCOM
etc.
So
the
RS
messages
are
sent
from
within
the
omni
interface
over
and
up
underline
any
other
interface.
D
The
process
is
coordinated
from
within
the
mom
knee
in
her
face
and
it's
opaque
to
the
ip6
layer.
So
all
this
is
going
on
below
the
ipv6
layer,
the
access
router
processes,
the
RS
message
and
conveys
the
omni
option.
Information
to
the
mobility
service
mobility
service
injects
the
mobile
network
prefix
into
the
writing
system.
Caches
the
prefix
length
and
moment
moment
are
prefixed
in
IFA
indexed
tuples
and
then
the
mobile
mobility
service
directs
the
access
router
to
return.
D
The
router
advertisement
message
to
the
mobile
node
again
with
an
omni
option
and
with
non
zero
router
lifetime.
If
the
prefix
registration
was
too
successful,
otherwise,
zero
mobile
node
receives
the
re
confirmation
and
then
the
access
router
will
be
set
to
forward
packets
between
the
mobile
node
and
the
mobility
service
next
chart.
Please.
D
Next
chart,
please
thank
you.
So
after
the
initial
registration,
when
in
Ain
a
face
transitions
to
up
the
mobile
node,
sends
an
omni
RS
message
when
it
interface
transitions
to
down
the
mobile
node,
can
send
an
unsolicited
neighbour
advertisement
message
over
any
up
a
net
interfaces
with
an
if'
index
tuple
for
the
down
interface,
with
link
set
to
zero.
D
So,
for
example,
if
I'm
IV
diamo
to
goes
down
I've
sent
in
a
UN
a
over
the
SATCOM,
the
mobility
service
gets
it
and
then
takes
the
video
mode
to
link
out
of
its
selection
process
for
for
trafficking
selection.
The
mobile
node
departs
from
a
current
mobility
service
endpoint.
It
can
send
an
RS
or
u
na
over
any
up,
inter
in
an
interface
to
release
that
mobility
service
endpoint.
When
the
mobility
sir
mobile
known
associates
with
the
new
mobility
service
endpoint,
it
sends
a
RS
or
RA
over
any
up
interface
with
a
mobility
service
register.
D
Now
one
thing
that's
interesting
about
this
is
that
with
when
we
have
multiple
mobility
service,
endpoint
servicing
the
same
mobile
node,
the
RS
are
an
RA
message.
Skinning
can
include
multiple
register
IDs
in
a
single
RS
message,
so
I
could
send
a
single
RS
message
over,
for
example,
my
video
mode
to
link,
and
it
would
register
with
multiple
mobility
service
endpoints
with
a
single
message
and
that's
that
that
amounts
to
a
very
large
saving
of
messages
over
low
data
rate
access
network
links.
D
So
then,
finally,
when
all
the
mobility
notice
unknown
faces
of
transition
to
down
or
if
the
prefix
registration
lifetime
has
expired,
the
mobility
service
with
bras
the
mobile
network
prefix
from
the
routing
system
start
please
so
now
that
all
this
has
been
set
up.
Because
of
all
the
are
sorry
messaging.
A
D
Skip
ahead
to
that,
one
thanks,
mom
thanks!
So
so
really
what
we
need
to
talk
about
now
is
the
status
of
this
document
in
next
steps.
This
document
has
been
a
work
in
progress
in
working
group
by
the
mobility
subgroup
of
ICAO
since
March
of
2019,
and
it's
now
published
as
an
IETF
internet
draft
yeah
there's
the
draft
name.
D
We
have
code,
that's
an
advanced
stage
of
development
and
testing
in
linux,
based
network
emulations
and
early
aviation
testbed
trials
also
other
relevant
trials,
such
as
enterprise
network
mobile
devices
and
in
our
liaison
statement,
we've
requested
the
IETF
to
adopt
the
work.
It's
an
example
of
an
ipv6
over
fus
back.
It
uses
the
new
ipv6
in
the
neighbor
discovery,
option
notice
the
omni
option
that
needs
to
be
standardized
and
it
uses
a
new
link.
Local
address
format,
notice,
the
Omni,
Omni
link,
local
address
format
and
we're
requesting
standards
track,
RFC
publication.
D
H
Hello
Fred:
are
you
okay,
yeah,
so
I
have
several
questions.
Some
are
more
details
on
how
level
higher
level
and
I
have
put
them
in
the
double
for
reference.
I
suspect
there
is
not
enough
time
to
discuss
them
all
now,
but
this
NLA
really
for
matter
on
the
on
the
omni
interface,
looks
like
a
link.
Local
address
that
integrates
in
its
interface
ID
part,
the
mobile
network,
graphics
and
an
example
is
given
on
slide
number
seven
with
mobile
network
prefix.
That
fits
well
because
it
has
a
prefix
of
maximum
four
hex
Ted.
H
D
Alex
and
done
is
we've
said
that
for
prefix
lengths
up
to
slash
64,
those
prefix
bits
we're
going
into
the
the
64
bit
interface,
identifier
of
fe80,
colon
colon,
slash
64
for
pretty
links
longer
than
60
for
the
additional
prefix
bits
would
begin
to
be
encoded
in
bits
10
through
63
of
the
ipv6
link
local
address.
So
what
this
allows
us
to
do
is
in
the
future.
D
I
O
Eric
line,
no
no
hats,
Thank,
You,
Fred,
I.
Think,
okay,
let's
set
aside
I,
see
a
colon
colon
slash
ten,
because
I
think
there
are
some
issues
there
right
by
convention.
It's
6054
that's
available
on
the
link,
but
I
guess
you're
going
to
say
this
is
different
for
this
particular
link.
But
I
had
a
question
about
like.
If
we
set
aside
the
MTU
reassembly,
the
MTU,
the
link
specific
variable,
MTU
and
reassembly
issue.
O
D
D
Are
slides
beyond
my
backups
here
that
I
think
we
have
time
to
go
into
Eric
I'd
like
to
ask
you
to
go
to
those
charts
and
look
at
what
they're
talking
about
in
terms
of
Viet
advantages
in
the
rationale
for
having
the
virtual
interface
some
of
the
points
that
will
be
included.
There
are
things
like
the
fact
that
you
don't
have
to
get
care
of
dresses.
If
you
will
the
access
network
interfaces,
if
you
use
the
virtual
interface.
O
Well,
you
know,
there's
no
there's
no,
but
he
seemed
to
rest
seemed
to
indicate
that
you
could
register
connectivity
link's
without
actually
sending
packets
over
them,
but
there's
a
certain
fake
sharing
about
being
able
to
make
sure
the
link
is
up
that
you
can
communicate
over
it
and
register
by
it,
but
I'm,
perhaps
III
said
I'll
believe
them
I'll
read
your
backup
slides,
you
know
I'll,
maybe
I'll
beat
it
up.
Thanks.
O
I
D
A
Yes,
thank
you
yeah,
so
I
think
this
is
all
very
interesting.
I'm
pleased
to
see
this
work,
being
you
know,
brought
to
the
ITF
I
think
there's
a
lot
of
work.
You
know
the
liaison
is
sort
of
a
work
in
progress
at
the
moment,
but
I.
The
one
thing
that
I
would
like
to
personally
like
to
see
is
that
some
more
just
at
least
more
justification
to
understand.
Why
there's
a
lot
of
things
here
which
are
not
well
beyond
at
ipv6
over
crew
spec,
it's
proposing
new
nd
options.
A
You
know
a
bunch
of
things
and
I
I'd
like
to
see
more
justification
for
why
those
things
are
necessary.
Why
I
sort
of
I
think
to
Eric's
question?
Why
why
can't
I
be
p6
just
be
used
as
currently
defined?
What
you
know?
What
is
the
benefit
here?
It's
it's
adding
a
lot
of
complexity,
I
realize
this
is
for
a
particular
sub
domain,
but
I
think
there's
gonna
need
to
be
a
lot
of
discussion
over
some
of
these
issues,
but
we
will
do
the
list.
Thank
you.
I
F
I
F
F
So
essentially,
there
are
a
lot
of
you
know
different
scenarios.
Some
are
more
common
than
others
in
which
you
might
have
a
horse
connected
to
a
network
and
all
out
of
the
sudden
another
configuration
changes
or
you
know
somehow
their
rotor
just
banishes
the
left-hand
side.
We
have
a
very
common
scenario
in
which
we
have
a
CPE
router
that
is
doing
prefix
delegation
with
the
ASB
and,
at
the
same
time,
is
doing
slack
on
the
on
the
home
network.
F
One
of
the
scenarios
that
might
happen-
and
that
is
common-
is
that,
for
example,
the
CPE
roller
crushes
boots
and
it
gets
a
different
prefix
leased
from
the
ISP.
In
most
cases,
the
CPE
rotor,
just
it
just
doesn't
record
on
stable
storage,
the
prefix
that
was
leased
before
so
when
the
rotor
reboots.
It
has
no
knowledge
of
the
you
know
previous
prefix
that
was
leased.
It
starts
advertising
a
new
prefix
on
the
local
network
and
all
the
notes
on
the
local
network.
All
the
hosts
keep
stale
information.
F
There
are
many
different
scenarios
in
which
this
kind
of
thing
can
happen,
as
I
have
mentioned
on
the
six
one
mailing
list,
we
have
a
basic
subs
working
group.
Hiding
item
discusses
the
problem
in
detail,
so
this
presentation
and
the
correspondent
draft
focus
on
the
protocol
updates
that
will
be
necessary
to
improve
SELEX
response
to
pre
numbering
events,
but
the
problem
statement
and
the
problem
itself
is
discussed
in
detail
in
a
physics,
ops
working
group
item
next
slide.
F
So
when
considering
you
know,
protocol
updates
that
would
be
necessary
or
would
be
valuable
to
you
know,
improve
the
reaction
of
select
to
remembering
events,
number
of
things
that
or
a
number
of
aspects
that
are
interesting
to
to
consider
one
is
about
signaling.
For
example,
we
have
two
options
in
some
scenarios:
the
router
itself
that
trigger
the
renumbering
event
continuous
operation.
F
It
may
be
aware
of
this
daily
information
or
me,
or
it
might
be
unaware
of
this
tale
information
sample,
in
one
case,
the
rotor
crashes,
which
the
router
had
stored
on
stable
storage,
the
information
about
the
prefix
being
unknowns,
so
the
router
we
boated
it
now
got
a
different
prefix
list
from
the
ISP.
It's
aware
that
the
information
has
changed.
So
it's
somehow
in
the
position
of
trying
to
deprecate
that
information.
In
other
cases
the
rotor
might
be
unaware
of
the
stale
information.
F
That
would
be
the
case,
for
example,
if
the
router
reboots,
it's
least
a
different
different
prefix,
but
the
rotor
doesn't
record
unstable
storage
prefixes
that
are
leased
by
the
ISP.
In
other
cases,
we
could
have,
for
example,
the
rotor
just
disappear.
For
example,
the
rotor
just
crashed,
or,
for
example,
a
switchboard,
was
moved
to
a
different
villain,
so
we
had
a
router
that
was
advertising
information
and
just
you
know
that
rotor
somehow
disappear,
whether
because
the
rotor
itself
disappear
or
because,
for
example,
as
I
mentioned,
a
switch
power
was
moved
to
a
different
billon.
F
If
you
apply
the
router
there,
the
improvements
on
the
on
the
hot
side-
and
that
means
that,
in
order
for
house
to
benefits
from
these
improvements,
they
don't
need
for
the
robbers
to
be
updated
and
that's
all
that's,
of
course
valuable.
On
the
other
hand,
you
know
if
apply
improvements
on
the
rotor
side.
That
means
that,
even
if
we
have
host
implementations
that
have
not
been
updated
and
improved,
it
can
nevertheless
yet
timelier
way
to
these
four
number
elements.
So
what
our
draft
tries
to
do
is
to
pursue
improvements
in
all
of
these
areas.
F
F
So
I
try
to
summarize
improvements
that
we
are
proposing
in
this
few
slides.
So
if
you
look
at
current
specification,
for
slack
specifies
they
prefer
lifetime
for
prefix
information
options
of
one
week
in
a
slide
says
one
day,
but
that's
incorrect.
The
current
fall
preferred
lifetime
is
of
one
week.
The
fall
valid
lifetime
is
of
one
month.
Of
course,
that's
the
equivalent
of
setting
timers
that
will
never
go
off.
F
That
means
with
a
default
default
value
for
the
roller
lifetime
will
use
a
prefilled
lifetime
of
half
an
hour
and
we
use
a
ballad
lifetime
of
so
we
use
the
preferred
lifetime
lifetime
from
one
week
to
half
an
hour
and
we
reduced
a
ballad
lifetime
from
one
month
to
one
day
the
other
hand
we
also
proposed
to
cap
they
receive
lifetime
at
host.
Of
course,
this
is
useful
when
your
horse
is
connected
to
a
network
and
then
and
the
local
router
is
still
using
the
default
values
currently
specific
in
RFC
48
61
correctly.
F
So
we
our
document,
poses
to
cup.
They
prefer
a
lifetime.
Router
lifetime
The
Ballad
lifetime
n
multiplied
for
the
road
of
lifetime
currently
being
developed
on
to
one
day.
So
that
means
if
the
advertised
had
lifetimes
are
longer
than
that,
then
use
those
life
stands.
This
means,
for
example,
when
it
comes
to
the
host
site
improvement,
even
if
the
router,
for
example,
disappears,
the
host
can
recover
later
next
slide.
F
There
is
another
issue:
if
you
look
at
section
by
point
five
point:
three
I
think
e
of
RFC
48
61.
It
essentially
prevents
the
valid
lifetime
in
Apio.
Reducing
valid
lifetime
associated
with
a
corresponding
addresses
do
anything
smaller
than
two
hours.
That
means
that,
if
you
were
sorry,
if
you
receive,
for
example,
a
Pio
with
about
a
lifetime
of
of
zero
day
receiving
cost
is
to
ignore
PA.
F
You
know,
from
our
point
of
view,
make
much
sense
to
just
these
PII
or
just
or
to
specify
the
it
was
to
be
ignored,
because,
from
the
point
of
view
of
from
the
point
of
view
of
an
attacker,
if
an
attacker
wanted
to,
you
know
just
implement,
for
example,
a
denial
of
service
attack.
It
has
like
it's
even
other
attack
vectors
like,
for
example,
food
costs
with
bogus
POS
or
wrote
information
spoof
rotor
advertisements
with
a
lifetime
of
zeros,
so
the
you
know
the
router
itself
is
disabled,
etc,
etc,
etc.
F
On
the
other
hand,
if
you
prevent
hosts
from
reacting
to
the
iOS
that
have
a
valid
life
that
smaller
than
two
hours,
then
you
prevent,
like
a
time
layer
reaction
to
remembering
events
in
situations
in
which
router
the
local
router
is
aware
that
you
know
network
configuration
information
next
slide
and
finally,
we
also
specify
a
couple
of
alternative
algorithms.
They
are
meant
to
do
the
same
thing,
so
I'm
just
going
to
describe
one
of
them,
but
the
other
one
is
very,
very
similar.
F
The
idea
is
for
host
to
actually
try
to
infer
when
there
were
configuration
information,
as
has
changed.
For
example,
this
would
be
the
scenario
in
which,
for
example,
a
router
crashes
gets
different,
prefix
leased
from
the
ISP
and
starts
advertising
these
new
prefix.
Now,
if
the
router
has
not
recorded
previous
prefix
on
stable
storage,
it
will
start
announcing
a
new
prefix
for
outer
configuration.
F
Obviously,
at
the
same
time,
it
will
cease
advertising
the
previous
prefix.
So
the
idea
is
simple
from
the
host
point
of
view.
If
you
see
that
the
same
router
that
was
advertised
in
a
previous
prefix
as
sees
advertising
that
prefix
and
has
started
advertising
annealing
graphics,
that
should
be
taken
as
an
indication
that
network
configuration
information
has
changed.
F
So
what
we
do
is
essentially
try
to
implement
that,
like
try
to
deprecate
the
stale,
prefixes
open,
received
of
route
revert
iseman
from
the
same
router
Ras
that
sees
to
advertise
ceased
to
advertise
the
previous
prefixes
as
a
kind
of
improvement
to
the
algorithm.
We
try
to
unfold
the
processing
of
ollas
and
the
process
utilized
and
the
processes
of
global
puffiness.
So
what
the
algorithm
does
is
this?
F
You
receive
a
rubber
advertisement
from
the
same
router
as
before
the
rotor
that
was
advertised
in
a
previous
prefix
RA
Alberta
is
new,
but
it's
in
the
previous
prefix.
What
you
do
is
you
reduce
they
prefer
lifetime
and
the
ballad
lifetime.
For
that.
Previous
prefix
we
currently
do
is
reduce
the
prefer
lifetime
in
the
order
of
a
few
seconds
just
to
accommodate
the
theoretical
scenario
in
which
the
configuration
information
may
be
split
into
multiple
word
advertisements.
F
We
reduced
the
ballad
lifetime.
If
I
remember
correctly,
we
reduce
it
to
an
to
the
other
of
about
half
an
hour,
or
maybe
even
obviously,
they,
the
ballad
lifetime
is
reduced
to
much
longer,
and
we
do
the
same
thing
for
you,
a
lace
if
you
receive
the
prefix,
that
is,
advertising
au
la,
but
it
doesn't
advertise
the
previous
usual
day.
You
reduce
the
preferred
lifetime
and
develop
lifetimes
accordingly.
F
At
the
same
time,
if
the
prefix
was
being
advertised
by
multiple
routers,
then
you
essentially
disassociate
these
Perfect's
with
this
specific
router.
We
are
talking
here
about
the
cases
where
we
are
having
scenarios
where
the
network
is
using
multiple
prefixes.
In
summary,
you
know
this
algorithm
is
able
to
deprecate
prefixes
when
a
new
prefix
is
being
offered
by
the
same
router.
The
same
role
is
not
has
cease
to
advertise
the
same
prefix
but
another
way
if
the
same
router
from
which
we
got
the
configuration
information.
F
F
Implementations
so
lately
we
have
been
working
in
on
implementations
of
the
things
we
did
implementations
for
a
number
of
demons
which
are
used
in
different
operating
systems,
so
these
slides
are
tries
to
summarize
existent
implementations
when
it
comes
to
using
the
lifetime
values
that
are
employed
by
router
implementation.
We
implemented
this
in
different
demons.
F
G
G
G
F
G
I
think
it's
kind
of
dangerous
for
default.
Behavior,
let's
say
I
have
a
router
I
have
two
routers
and
I'm
going
to
drain.
One
and
I
did
not
specify
explicitly
lifetime
in
configuration.
So
now
the
first
router
it
will
put
zero
pair
your
preferred
lifetime
well,
which
will
indicate
to
host.
Oh,
please
duplicate
the
prefix
I
think
you
should
be
very
careful
about
dealing
with
zero
lifetime
in
arrays
in
zero
router
lifetime
in
all
right.
What
router
she'll
be
there?
Okay,.
F
I
meant,
to
be
honest,
I'm
not
sure
if
we
had
considered-
and
we
have
consider
that
specific
case,
but
I
mean
point
taken
and
we'll
take
this
into
according
to
the
next
revision.
Thanks.
Thank.
C
You
and
Philip,
okay,
so
first,
a
general
comment:
I
think
this
is
an
important
thing
that
should
be
soft,
and
certainly
changes
on
the
host
would
help
to
solve
this
quickly
because
it
will
take
forever
for
all
the
routers
to
get
updated.
The
thing
that
has
me
worried
about
is
the
inferring
stale
information
thing.
C
It
seems
that
the
algorithms
that
Fernando
is
working
on
a
fragile
are
not
reactive,
since
I
introduced
an
issue
with
if
you
alternate
normal
global
user,
unique
address
in
your
lace
and
now
the
algorithm
has
become
more
because
it
has
to
do
separate
processing
for
your
lace.
But
even
then
it's
not
clear
if
we
should
build
in
just
one
type
of
your
lay
into
a
house
and
then
later
be
stuck.
If
we
want
to
have
another,
you
Elaine
my
concept
and
then
find
out
that
it's
going
to
fail.
C
I
Time's
up
times
that
won't
Philip
I
think
that's
a
very
important,
very
important
comment.
We
have
to
be
sure
that
we
end
up
with
not
the
less
robust
protocol
coming
out
of
this
I
think
we
should.
You
know,
work
together
and
thirdly,
look
at
other
protocol
implications
here.
So
thanks
thanks
a
lot
have
the
arocs
so
Belgian
Eric,
first
and.
A
E
So
what
makes
me
cut
me
off?
Okay,
hello,
Anna!
No!
This
is
a
ring
rank
here,
also
on
slide
six,
it's
typical
for
wrought
advertisement
to
be
sent
multiple
times
by
the
router,
because
all
the
messages
and
all
the
UPS
in
the
route
advertisement
can
really
longer
than
a
single
array.
So
it
could
be
common
that
one
pair
we
send
in
rutterbat
iseman
one
and
another
Pio
is
sending
rutterbat
Iseman
number
two,
so
different,
whatever
ties
one
from
the
same
router.
E
Furthermore,
there's
also
possibility
that
and
quite
common
nowadays
that
uncertified
multicast
it
arrays
and
not
sent
every
minute,
or
so
they
are
sent
much
longer
when
the
frequency
is
much
higher,
simply
because
we
want
to
reduce
the
numbers
of
multicast
array.
So
basically
the
assumption
where
you
buy
this
was
a
graden
is
maybe
need
to
be
reviewed
right.
Oh
I,.
B
F
E
F
That's
correct
and
there
are
two
things
like:
essentially,
you
can
accommodate,
for
you
know
to
those
cases
by
setting
these
two
values.
You
know
they
prefer
lifetime
that
you
said
the
PIO
and
the
lifetime
that
you
said
the
a
ballad
lifetime.
You
said
so
in
this
case
you
could
say
that
the
five
seconds
is
more
aggressive.
Now,
if
you
wanted
to
accommodate,
for
example,
to
two
other
cases
like
you
know,
when
the
options
are
split
into
multiple
messages
and
the
packets
are
lost,
etc,
etc,
etc.
These
lifetimes
could
be
increased.
E
G
E
A
E
R
So
on
the
topic
really
I,
think
I
was
going
to
reiterate,
fernando's
I,
guess
beyond
how
the
videos
are
generally
seen
in
the
same
array,
but
it
wasit
is
supported.
It
could
be
in
separate
ones,
but
also
we
could
look
at
triggering
rooted
solicits,
perhaps
including
the
PIO
option
in
the
solicit.
It's
a
bit
more
of
a
I
guess
a
reactive
approach,
as
opposed
to
just
a
committing
timers.
I
We
definitely
have
to
continue
this
on
the
on
the
list,
I
think
and-
and
do
you
know
some
thorough
reviews
and
discussions
on
this
I
think
that
has
been
very
useful
Bob.
Do
you
want
to
see
the
save
the
year?
Yeah
we'll
run
our
time,
so
we
skipped
for
normal
second
sessions.
We
have
to
do
that
on
the
mailing
list,
but
the
Bob
do
you
want
to
see,
say
the
farewells
and
summary?
Yes.
A
Thank
you
yeah.
So
thanks
for
everyone
for
joining
Olli
and
I
will
talk
about
whether
we
want
to
schedule
a
second
interim
meeting.
I
think
this
generally
worked
pretty
well,
we
could
do
the
talking
and
then
there
were
some
other
things
we
had
queued
up
for
our
ATF
107.
That
obviously
haven't
happened,
so
we'll
we'll
be
back
in
touch
on
that
I
think
the
webex
and
general
work
pretty
well
so
wish
you
all.