►
From YouTube: IETF110-6MAN-20210311-1600
Description
6MAN meeting session at IETF110
2021/03/11 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
A
A
Next
slide,
so,
as
we
talked
about
earlier
this
session,
we're
going
to
have
now
is
sort
of
a
structure
around
the
way
we
normally
do.
A
working
group
session
we're
going
to
have
document
status,
a
report
from
the
spring
compression
design
team
working
group
drafts
and
two
active
or
two
active
in
individual
drafts.
A
B
B
The
gratuitous
document
is
awaiting
a
new
id
from
the
author
and
for
the
oam
document.
It's
in
last
call
requested
state
the
ipv6
application
or
the
alternate
marking
method.
That's
on
the
agenda
for
today.
It's
just
going
through
the
last
call
comments
and
it's
on
the
chairs
to
to
do
the
write
up
and
advance
that
document
to
the
isg,
the
compact
routing
header
document.
It's
still
awaiting
the
sr
design
team.
B
We
have
a
talk
on
that
just
following
now,
and
we
have
two
working
group
documents:
it's
the
minimum
path
empty
hop.
I
hope
option,
that's
not
on
the
agenda
for
today
and
we
have
the
improving
the
robustness
of
slack
by
fernando
and
that's
on
the
agenda
later
any
comments
on
document
status.
Before
we
move
on
to
the
sr
design
team
talk.
B
C
C
C
Discuss
this
draft
and
we
post
the
000
revision
already,
but
in
this
revision
I
think
we
just
give
some
template
and
we
have
some
proposed
text
for
that
draft.
But
we've
not
have
enough
time
to
review
that
within
design
team.
So
we
did
not
post
those
proposals,
but
we
are
confident
that
we
can
generate
a
full
version
of
the
analysis
draft
soon.
C
As
I
just
mentioned
in
the
latest
version,
we
have
included
all
the
requirements
we've
received
and
the
design
team
have
gone
through
all
of
them
till
now,
only
three
of
them
with
rough,
but
not
a
universe,
concerns
within
design
team.
Now,
anyway,
we
have
a
poster
all
of
them.
This
is
three
items
we
put
it
to
appendix.
C
C
I
think
these
three
items
are
very
important
items.
They
are
srv6
based,
sr6
functionality,
so
I
think
it's
a
big
progress
for
the
design
team.
We
can
get
agreement
on
those
items
and
we
also
added
none
items,
new
items
with
the
rider
highlighted
text
and
those
items
covers
address
planning,
comprision,
libraries
and
as
a
domain
protections
security,
and
something
like
that.
We
think
that
has
data
our
fundamental
requirement
for
the
compression
solution.
C
C
C
C
C
C
C
So
here
are
some
completion
plan
for
analysis.
So
before
the
ietf
meeting,
I
think
we
have
already
done
a
lot
of
work
and
the
next
step.
We
have
a
rough
plan.
In
the
middle
of
april.
We
will
complete
remaining
analysis
text
proposal
for
the
design
team
review,
because
when
the
spring
working
group
writes
the
design
team,
they
hope
we
can
provide
some
concerns
document
to
the
working
group.
C
So
we
will
do
the
design
team
review
and
first
and
we
hope
to
provide
a
preliminary
version
at
the
end
of
april
so
that
the
people
in
spring
working
group
can
review
it
and
accommodate
it
and
at
a
later
may
we
hope
to
submit
a
new
revision
for
itf
spring
working
group
and
the
six-month
working
group
for
review,
because
the
analysis
draft
included
some
solution,
which
is
from
six
mind
a
working
group.
So
we
hope
the
review
can
be
done
in
the
both
working
group.
B
D
D
This
is
leading
and
these
delays
are
leading
to
the
ietf.
Sadly,
in
my
view,
contributing
to
a
lack
of
standardization
when
products
are
being
developed
on
top
of
code
points
that
people
are
using
and
at
the
end
of
the
day,
when
those
code
points
have
to
change,
because
we
can't
get
code
points,
etc,
etc.
D
E
C
I
think
andrew
asked
the
similar
question
in
last
spring
meeting
and
for
me
I
always
ask
myself
one
question:
why
we
come
here
for
ietf
meeting,
because
we
want
to
standardize
the
best
solution,
all
the
proper
solution
for
operators
and
the
vendors
and
the
here.
I
think
the
analysis
dropped
here.
We
list
at
a
list
of
four
different
solutions
in
the
from
my
point
of
view,
I
don't
know,
and
the.
C
E
C
F
First,
I'd
like
to
support
what
way
ching
said
taking
our
time
to
get
it
right
is
important,
but
I'd
also
like
to
support
what
andrew
said:
there
is
shipping
code
behind
each
of
them
and
squatting
on
good
points
is
not
a
good
thing.
Early.
This
year,
the
chairs
and
I
started
talking
about
an
rfc,
7120
early
code,
point
allocation
and,
I
believe,
that's
gone
to
the
80s.
F
G
Eric
yeah,
one
thing
I
wanted
to
understand
for
the
early
allocation
was
the
number
of
deployments,
so
the
could
anybody
speak
to
deployments
that
actually
need
to
interoperate
as
opposed
to
within
sort
of
one
administrative
domain,
or
is
there
like
a
linux
kernel
development
work?
That's
going
on
that
would
need
something
a
code
point
to
then
be
tested
for
interoperability
with
with
another
implementation.
D
G
H
Then
there
this
is
there
yeah,
so
I
just
want
to
back
up
weight
chang
on
those
on
those
timelines.
I
mean
on
february
11th
I
sat
down
and
and
reread
a
few
of
the
proposals
and
came
up
with
analysis
that
I
posted
to
the
design
team
and
at
the
time
the
design
team
decided
that
we
couldn't
hit
the
february
22nd
date
for
publication
with
internal
review.
H
So
there's
I
guess,
there's
the
there's
the
implementation
with
with
andrew
on
his
network,
but
I
in
as
part
of
that
is,
do
the
authors
expect
there
to
be
no
further
changes
and
that
everything
would
be
backward
compatible
with
that
with
any
code
points
assigned.
I'm
just
curious
on
that
point
as
well.
A
I
J
D
A
F
Regarding
the
stability
of
the
draft,
the
format
of
the
extension
header
hasn't
changed
in,
I
think
about
18
months
now.
A
couple
optional
elements
were
added
to
the
crh
fib,
mostly
as
a
response
to
what
was
going
on
in
this
design
team,
they're,
optional
and
because
they're
optional,
they
don't
present
a
backwards
compatibility.
K
F
Finally,
an
early
allocation,
you
know
if,
if
it
turns
out
that
this
doesn't
fly,
early
allocations
are
taken
back,
so
the
risk
associated
with
an
early
allocation
is
minimal,
especially
considering
the
fact
we
have
255
routing
types
to
assign
of
those
we've
assigned
only
five
or
six
in
the
last
25
years.
So
I
don't
think
there's
any
risk
that
we're
going
to
run
out
of
them
risk
of
making
this
allocation
is
minimal,
and
I
question
why
the
opposition
to
it
is
so
strong.
C
B
B
B
B
L
L
L
D
L
Will
go
through
a
few
slides
to
summarize
the
main
contents
of
the
graph,
so
this
is
this
slide
just
gives
a
night
level
view
of
the
alternate
marking
method,
so
there
are
two
reference
documents:
rfc
321
and
therefore
88.89
about
the
methodology.
The
first
one
describes
the
base
methodology
that
consists
of
that
batching
packets,
based
on
an
interval
for
target
class
measurement
and
to
select
within
a
second
flag,
a
new
set
of
market
packets
for
delay.
L
L
L
This
is
important
because
it
means
that
you
have
to
skip
if
you
don't
recognize
and
data
the
non-changing
route
according
to
rfc8200
and
the
other
important
fields
are
about
the
two
marking
fields
that
are
important
for
the
application
of
alternate
marking
methods,
of
course,
and
the
other
one
is
about
the
flow
monitor
identification.
That
is
required
for
a
specific
reason
that
I'm
going
to
explain
in
the
next
slide.
L
L
This
is
required
for
some
specific
reason.
We
it
helps
to
reduce
the
per
node
configuration
and
also
allow
a
flexible
granularity
for
the
flow
definition.
It
simplifies
the
counters
handling
and
also
it
eases
and
simplified.
The
export
of
that
there
were.
There
was
also
some
discussion
about
the
disambiguation
of
this
identification,
but
in
any
case,
there
are
two
options:
if
a
centralized
controller
can
extract
the
nodes
properly
can
guarantee,
of
course,
the
uniqueness
of
this
identification.
L
Why,
in
case
this
identification
is
randomly
generated
by
the
source
node,
there
is
a
chance
of
collision,
but
it
depends
of
the
application.
It
can
be
enough
to
have
a
50
percent
of
collision
for
1
000
to
other
clothes,
but
if
this
is
not
enough
to
have
more
to
to
have
more
entropy,
the
this
identification
can
be
combined
with
other
flow
information
in
the
packet,
for
example.
Yes,
the
addresses
or
the
flow
labels
next
slide.
L
L
Have
you
just
recap
about
the
alternatives?
Also,
we
change
the
little
wording
of
this
to
to
be
aligned
with
the
earthquake,
zero,
zero
and
thanks
to
brian,
for
this
suggestion.
So,
basically
you
you
can
have
the
destination
option,
not
preceding
the
routing
header,
and
in
this
case
the
measurement
can
be
done
only
by
the
the
node
in
this
mission
address
or
you
can
have
help
by
up
option
and
every
router
on
the
path
can
do
the
measurement.
L
L
L
In
addition,
an
attacker
cannot
gain
information
from
a
single
monitoring
point,
because
you
need
a
synchronization
between
different
monitoring
point
to
to
gain
network
performance
information.
So
this
is
also
another
aspect
that
is
in
favor
of
this
methodology
regarding
the
privacy
concerns
that
are
very
limited,
because
the
limited
marketing
techniques
is
unlikely
to
increase
the
existing
privacy
risks
and,
in
addition,
it
is
applied
to
to
the
option
either
and
without
any
release
of
use
of
that.
L
L
D
L
I
also
noticed
that
the
alternate
marking
leads
carried
by
the
option.
Adder
may
affect
the
pattern
view.
Of
course
this
is
this
is
true,
and
we
we
also
add
a
paragraph
in
the
security
considerations.
Anyway,
we
we
must
all.
It
is
important
also
to
note
that
the
relative
small
side,
so
only
48
bit
of
this
option
and
it's
together
with
this
application
to
control
a
domain
mitigate
this
issue.
B
So,
as
I
mentioned
during
the
document
status,
we
were
planning
on
the
next
step,
for
this
was
to
to
to
close
the
last
call
and
do
a
write-up
and
advance
it
to
the
isg.
Is
there
anyone
who
have
any
comments
now
that
we
need
to
do
prior
to
doing
that?
Please
jump
in
to
the
queue.
Otherwise,
we
will
proceed
on
that.
A
A
O
L
Q
P
P
You
know
at
the
time
we
have
an
individual
submission
that
had,
like
you
know
several
kind
of
orthogonal
mitigations
for
this
problem,
so
the
decision
at
the
time
was
to
before
actually
incorporating
into
the
working
group
document.
Those
mitigations,
essentially,
you
know,
discuss
each
of
them
in
the
working
group,
and
you
know,
based
on
on
on
working
group,
consensus,
decide
whether
or
not
to
incorporate
them
into
the
working
group
document.
P
P
So
essentially,
the
the
individual
version
had,
like
you,
know,
a
proposed
mechanism
and
what
we
have
and
that
you
know
that
mechanism
resulted
quite
a
little
quite
a
bit
of
of
discussion
and
not
everyone
was
happy
with
it.
So
one
thing
that
we
did
since
then
is
first
of
all
try
to
stay,
take
a
step
back
and
you
know
think
about.
You
know
how
these
mediation
should
work.
P
Okay,
so
essentially
we
can
say
that
the
mitigation
for
let's
say
getting
rid
of
state
information,
has
two
parts
part
of
it
is
the
trigger
like
something
that
happens
in
the
network.
That
makes
you
think
that
you
know
that
might
be
an
indication
that
there
is
information
that
has
become
stale
and
then
there
is
the
second
part,
which
is
the
actual
check.
What
do
you
do
to
actually
check
that?
That
information
has
indeed
become
stale,
so
the
mitigation
that
we
had
initially
didn't
separate?
P
You
know
between
these
two
parts,
and
you
know
it
was
just
you
know
the
the
mechanism
proposed
right
away,
so
we
kind
of
like
we
thought
this
idea
quite
a
bit
when
it
comes
to
the
trigger.
That's
probably
the
easy
part:
okay,
so
the
obvious
trigger
you
know
for
checking
whether
the
information
has
become
stale
or
not
is
the
receipt
of
a
router
advertisement
that
contains
missing
information.
P
B
P
B
P
Okay,
so
long
story
short,
we
have
we
reanalyzed
the
mediation
that
we
had
and
what
we
did
was
separate
it
into
two
parts
a
trigger
and
the
actual
check
the
trigger
is
what
will
make
the
host
say?
Okay,
you
should
probably
double
check
whether
this
information
is
a
stale
or
not,
and
the
check
is
what
you
actually
do
to
figure
that
out.
The
obvious
thing
for
the
trigger
is
the
receipt
of
of
an
array
that
is
missing
previous
information
in
this
case
pios.
P
So
you
don't.
Actually
you
were
not
actually
checking
whether
the
information
was
still
or
not,
but
you,
you
know,
reduce
the
lifetimes
like
to
small
values,
for
example,
they
prefer
lifetime.
In
the
order
of
you
know
a
few
seconds,
okay
or
on
the
other,
let's
say
five,
ten
twenty
a
minute
but
small
value,
and
that
is
a
valid
lifetime
to
us
to
a
few
minutes
now.
If
they
were
not
stale,
they
would
be
refreshed
and
that's
it
so
the
check
was
kind
of
like
implicit.
Okay.
P
There
is
another
option
which
is
also
kind
of
like
an
implicit
check
which
is
to,
for
example,
when
you
receive
an
array
and
it's
missing
information
rather
than
do
like
a
more
aggressive.
I
receive
reduction
of
you
know
of
the
lifetimes,
for
example
health
health,
these
lifetime
values.
So
the
reduction
won't
be
that
aggressive.
But
you
know
you
will.
You
know
eventually
reduce
like
the
this,
like
the
the
lifetime
left
exponentially.
P
Okay,
now
what
we
finally
selected
to
do,
which
is
probably
the
most
conservative
option
option-
is
to
do
like
an
explicit
check.
So
when
you
receive
an
aid,
an
array
that
is
missing
information,
what
you
do
is
essentially
you
schedule
that
of
sending
a
router
solicitation
to
the
router
that
sent
you
the
information
to
double
check,
whether
that
information
is
stale
or
not.
P
If
you
know,
while
you
have
scheduled
the
rs,
you
receive
the
information,
then
that's
fine.
You
don't
even
need
to
send
the
arrays,
because
the
information
is
there
and
in
the
case
that
you
schedule
that
of
sending
a
router
solicitation
and
in
the
meantime
you
don't
receive
it.
Then
you
will
send
a
unicast
router
solicitation
and
what
we
propose,
which
is
in
the
in
this
in
the
next
slide,
is
that
you
can.
P
I
mean
I
personally
think
that
you
know
if
you
check
with
an
rs
once
that
should
be
more
than
enough,
but
you
know
if
folks
want
to
be
even
more
conservative,
you
can
actually,
you
know,
do
you'll
send
our
an
arrays
like
multiple
times,
so
you
retry
multiple
times
you
pull
the
router
multiple
times
to
see.
If
you
know
you,
if
the
ro,
the
router
eventually
sends
you
that
information
that
was
missing
next
slide,.
P
P
It
means
that
you
know
it's
like
normal
behavior,
what
we
have
right
now
and
if
this
flag
is
set
to
true,
that
means
that
we
are
in
the
process
of
double
checking
with
that
router,
whether
the
information
you
know
is
fresh
or
not.
So
if
you
receive
an
array-
and
you
know
you-
you
are
not
currently
refreshing
the
information,
then
you
check
the
pios.
If
any
of
them
is
missing,
then
that
means
that
you
have
to
enter
this
router
refresh
mode
if
you
wish.
So
what
you
do
you
enter
this?
P
You
set
this
flag
rotor
refresh
to
true,
and
then
you
mark
what
are
the
pios
that
are
missing.
That
is
pios
that
you
had
received
from
that
router
before,
but
that
are
missing
in
this
packet
and
the
next
thing
that
you
do
is
you
set
the
timer?
You
are
scheduling
a
timer
so
that
to
schedule
a
router
solicitation.
Okay.
P
Now,
if
you
receive
a
an
array,
okay-
and
you
were
refreshing
information,
the
only
thing
that
rooted
refresh
was
true.
The
only
thing
that
you
have
to
do
is
look
at
the
pios
and
clear
the
ones
that
you
just
received
so
you're
keeping
track
of
which
of
which
ones
are
missing.
So
if
your
refreshing
information,
then
you
check
the
bios,
the
ones
that
you
have
received,
you
clear
them:
okay,
so
that
means
that
those
are
fresh
still
fresh.
Now
what
happens
if
the
timer
expires,
the
timers
that
you
have
set
up
before
expires?
P
Well,
what
you
do
is
if
all
the
pios
have
been
received.
That
means
that
essentially,
all
the
information
is
fresh,
so
you
just
clear
this
wrote
refresh
flag.
So
you
are
refreshing
information,
but
you
have
received
everything
that
you
were
meaning
to
receive
problem
solved.
Okay,
then
you
have.
We
have
a
secret
option.
If
you
have
retransmitted
a
router
solicitation
more
than
whatever
time
whatever
number
of
times
the
working
group
wants
to
do,
it
could
be
once
if
you,
if
you
know
we
agree
that
once
is
enough,
but
it
could
be
10.
P
If
that's
what
the
working
group
thinks
is
the
most
conservative
option?
Fine
enough,
but
if
you
have
retransmitted
you
know
the
arrays.
That
number
of
times
then
essentially
disassociate
those
pios
with
a
router.
That
is,
you
have
checked
with
the
router.
That
means
that
that
information
has
become
stale.
Then
you
have
to
get
rid
of
it
now.
In
the
other
case,
that
is,
the
timer
has
expired.
What
you
do
is
send
the
router
solicitation,
so
the
concept
is
quite
simple:
you
get
an
array
that
has
missing
pios,
you
schedule
the
timer.
P
If,
before
the
timer
expires,
all
the
information
has
been
received
in
other
are
in
other
arrays,
then
problem
solved.
Otherwise
you
send
a
number
of
times
as
many
as
necessary,
unicast
router,
solicitations
to
the
router
to
double
check
whether
that
information,
you
know,
is
there?
If
you
have,
you
know
retransmitted
the
rs
and
sufficient
number
of
times,
then
you
give
up
and
you
remove
that
information
next
slide.
P
So
comments
this
is
not
necessary,
so
I
could
have
easily
you
know,
you
know,
remove
this
slide,
but
some
things
you
know
could
be
made
easier
like
even
simpler
if
all
options
of
the
same
type
could
be
required
to
be
in
the
same
ra
packet.
This
is
I
I
stress
this
like
strongly.
This
is
not
required
for
the
mechanism
that
we
just
discussed.
Okay,
I'm
just
saying
that
if
we
were
to
do
that,
if
we
were
to,
you
know,
enforce
this
other
requirement,
things
would
be
even
simpler,
but
this
is
not
required.
P
Okay,
so
if
we
were
to
require
all
options
of
the
same
type
to
be
in
the
same
packet,
this
could
be
even
simplified,
because
you
know
right
now.
4861
essentially
says
that
you
can,
you
know,
split
the
information
among
any
number
of
packets,
that
you
want
even
options.
From
the
same
time,
for
example,
you
could
have
to
send
like
say
10
pios
and
you
can
send
each
pio
in
each
pio
in
a
different
array,
but
again
this
is
not
required
for
this
mechanism
to
work
next.
One.
P
So
question
is:
if
there
are
any
comments
or
concerns
about
this,
so
the
idea
is
that
you
know
that
what
was
you
know
agreed
was
that
you
know
things
would
be
discussed
with
a
working
group
before
we
would
actually
incorporate
them
into
the
working
group
document.
So
this
is
this
part.
If
there
are
comments
or
concerns
about
this,
this
mechanism,
that
you
know
we
have
proposed
and
if
they're,
if
there
are
not,
we
can,
you
know,
send
the
detailed
text
to
the
mailing
list.
A
A
A
A
So
I
mean
the
underlying
problem:
is
that
hopper
hop
options
are
not
working
end-to-end
in
the
internet.
You
know
it's
common:
that
packets,
with
hot
pie
options
get
dropped.
I
think,
based
on
the
measurements
that
gory
and
anna
did
regarding
the
path
mq
option.
I
think
we
discovered
that
there
are
some
edge
routers.
You
know
the
the
isp
that
who
serves
the
actual
customer
were
just
dropping
these
they
didn't
want.
A
They
didn't
want
packets
to
go
to
the
the
slow
path
they
didn't
want
to
have
them
interfere
with
the
operation
of
the
router,
and
so
my
conclusion
was
that
you
know
we
need
to
do
something
different
if
we
expect
hot
pie
up
options
to
be
useful
in
the
future.
Right
now,
they're
not
very,
very
useful,
and
this
is
an
approach
to
try
something
different.
A
I'm
not,
I
think
neither
of
us
are
sure
this
is
the
perfect
solution,
but
it
wanted
to
entertain
thinking
about
this
and
how
we
might
make
this
better,
so
next
slide,
and
so
by
the
way,
so
I'm
gonna,
basically
the
way
the
presentation
is
organized.
It
first
basically
talks
about
what's
in
the
draft,
and
then
it
has
a
section
that
goes
through
the
issues
that
were
raised
in
the
mailing
list
discussion
and
I
think
I
captured
them
all.
A
A
You
know
it's
the
way,
it's
the
usual
processing
in
the
router
for
most
packets.
You
know
it's
how
you
get
wire
speed.
It's
also
a
lot
of
times
called
the
forwarding
plane
and
the
slow
path
is.
You
know
where
packets
that
are
usually
processed
by
the
router
go
in
a
lot
of
cases.
It's
software
processing,
you
know
so
it's
used
for
special
processing,
it's
where
routing
protocols
go
and
the
like.
A
A
I
think
this
is
really
only
talking
about
routers
with
specialized
hardware
forwarding
software
only
routers,
I
think
don't
have
this
issue,
but
I
think
the
denial
of
service
attack
is
still
an
issue
even
in
software
next
slide-
and
you
know,
motivation
again
is
hoping
hop.
Options
are
not
practical
currently
to
be
used
widely.
It's
common
to
drop
packets
without
by
hub
options.
A
I
think
multiple
options
make
the
problem
worse
and
any
mechanism
that
you
know
that
packets
extent
that
are
sent
externally
to
slo
to
slow
down
a
router
is
can
be
exploited
as
a
denial
of
service
attack
and
the
goal
goal.
When
I
wrote
this
was
to
redefine
the
procedures
to
make
alpe
options
more
practical
to
use
because
I
think
they
are,
they
have
a
lot
of
good
potential,
but
you
know
right
now:
it's
you
know.
You
can't
use
them
consistently
across
the
internet.
A
A
The
change
is,
one
of
the
changes
is
only
to
allow
one
hop-hop
option
in
the
header
and
this
results
in
requiring
that
all
hop.
I
hope
options
be.
Eight
octet
aligns
because
aligned
because
the
way
the
pop-up
option
header,
you
know
it
has
to
be
eight
octet
aligned,
and
so,
if
it
was
shorter,
then
you
would
need
pads,
and
I
was
trying
to
avoid
that
as
I'll
talk
about
later,
it
turns
out
most
currently
defined.
A
Hop-Up
options
are
eight
octet,
aligned
and,
and
as
part
of
this,
I'm
saying
that
nodes
must
discard
packets
with
more
than
one
option
next
slide
and
the
other
big
change
is.
Basically,
if
you
can't
process
a
hop
by
hop
head
option
in
the
fast
path
you
you
know,
or
the
processing
must
be
done
in
the
fast
path
and
and
then
this
is
a
change
and
it's
a
significant
change.
Is
that
saying
here?
A
Another
change
is
that
section
4.2
and
rfc
8200.
You
know
the
bits
in
the
first
bits
in
the
type
field
define
what
to
do,
what
to
do
with
the
option.
If
it's
not
recognized
and
I'm
basically
changing
it
to
0
0
will
mean
skip
this
option,
continuing
processing
and
then
otherwise
discard
the
packet,
and
the
change
here
is
to
not
no
longer
require
the
sending
of
icmp
error
messages
which
I
suspect
is
problematic
at
full
speed.
A
A
To
see
if
an
option
is
supported
in
the
router
and
if
not
follow
the
what
it
says
in
the
bits
in
the
option
type
field,
whether
to
just
drop
it
or
to
skip
it
next
slide,
and
so
I
went
through
the
existing
options
and
this
lists
the
options
that
are
hop
options.
There
are
some
other
options
that
are
either
deprecated
or
our
destination
options:
destination
header
only
options,
so
I'm
not
showing
those-
and
I
discovered
that
many
of
these
are
eight
octet
aligned.
A
A
A
Slide
and
of
course,
then
any
new
hop-up
options
defined
must
have
eight
octet
alignment.
It's
probably
also
good
to
include
when
they
should
be
sent.
Do
they
need
to
be
in
all
packets?
Can
they
be
in
occasional
packets?
You
know
using
the
path
mtu
option
as
an
example
that
those
are
particularly
not
intended
to
be
in
all
packets,
because
in
fact
they
only
want
to
be
in
the
short
packets,
not
in
the
long
packets,
because
otherwise
they
they
won't
do
what
you
want
them
to
get
in
through
the
network
end
to
end.
A
A
I
wouldn't,
I
think,
that's
not
a
good
idea.
I
think
it
would
make
it
harder
to
process.
I
think
the
current
ipv6
design
of
making
them
always
be
the
first
one
is
intended
to
make
it
easier.
You
don't
have
to
look
through
the
whole
packet
in
the
fast
path
to
see
if
there's
any
there.
I
think
I
think
that's
a
very
good
property.
I
don't
think
we
want
to
lose
that
next
was
reduces
flexibility
to
have
only
one
hop.
A
I
have
option
and
fast
path
only,
and
it
is
true,
it
does
reduce
flexibility,
but
you
know
our
current
amount
of
flexibility
has
made
this
not
be
useful
across
the
end
to
an
internet.
Another
you
know
issue
is
you
know,
restricting
options,
isn't
the
right
approach
and
it's
you
know
it's
it'd
be
nice.
A
I
mean
we
could
the
document
could
be
changed
to
make
this
a?
Should
you
know?
Do
it
this
way
unless
you
have
a
good
reason
not
to
I
mean
that
certainly
also
covers
software
implementations,
but
we
do
have
the
issue
about
you
know
if
you
do
allow
them
to
go
to
the
slow
path,
then
how
do
you
avoid
this
becoming
used
as
a
denial
of
service
attack?
You
know
if
you
keep
them
in
the
fast
path
and
you
only
process
the
ones
that
you
are
configured
to
do
then.
A
A
You
know
you
know,
but
how
many
hop
I
hop
options
are
should
be
allowed.
You
know
I'm
proposing
one
and
it
is
restrictive.
I
agree,
but
different
hopper
options
could
be
used
in
different
packets.
You
know
they
don't
all
have
to
be
in
the
same
ones,
don't
need
to
be
in
every
package.
Obviously
it
depends
on
the
design
of
the
option.
A
You
know
the
path
mtu
option
is
particularly
designed
to
not
be
in
all
packets,
and
I
think
that
could
be.
You
know
I
I
mean.
Maybe
a
general
comment
here
is
that
hop.
I
hop.
Options
can
be
a
very
useful
and
powerful
mechanism,
but
if
they're
overused,
then
it's
sort
of
it
sort
of
breaks
the
ability
to
use
them,
and
so
I
think
they
need.
You
know
thinking
about
this
in
the
future.
A
I
think
we
need
to
be
careful
about
what
we
would
define
as
hot
by
hop
then
there's
the
you
know
would
would
a
different
limit
be
better
as
opposed
to
any
number
could
we
have
two
three
four
etcetera,
and
you
know
I
sort
of
wonder
how
much
flexibility
do
we
need.
I
mean
we
know
that
the
current
mechanism
isn't
working
end-to-end
in
the
internet.
A
A
Then
you
have
to
have
a
way
of
the
host
need
to
know
how
many
to
send
and
in
unless
you
also
have
the
requirement
for
a
octet
alignment
that
you
you
may
need
to
use
the
pad
options
which
makes
it
more
complicated
and
then
the
last
one
was,
if
there's
more
than
one
you
know.
Should
this
be
a
global
or
a
node
limit,
and
I
think
it
probably
wants
to
be
global.
A
A
A
A
A
Of
course,
any
router
any
node
can
look
at
anything
if
they
choose
to,
we
don't
we're.
Not
the
protocol
police
will
forwarding
packets
with
unknown
hopper
hop
options
work
at
the
edge.
I
think
that's
a
good
question.
You
know
right
now.
We
have
examples
of
you
know,
isps
at
the
edge
dropping
packets
with
hot
pipe
options
with
will
they
let
them
through
will
firewalls
and
the
like?
A
Allow
top
high
options
they
don't
understand
through.
That's,
I
think
something
we
need
to
understand
better
and
then
this
general
question
is
operational
deployment
possible.
You
know
this
can
require
changes
in
all
all
nodes
to
be
useful,
and
I
think
clearly
this
will
take
time.
It
can
request
and,
of
course,
require
support
from
router,
vendors
and
operators.
You
know
vendors
have
to
build
this
in,
and
operators
have
to
decide
it's
useful
to
allow
it
to
be
used.
A
F
Yes,
if
you
look
today,
you'll
find
many
drafts
trying
to
repurpose
bits
in
the
base
ipv6
header,
because
what
they
really
need
is
a
hop
extension
header,
but
you
know
they
don't
have
one
that
works.
So
for
that
reason,
I
think
that
this
draft
is
probably
the
most
important
draft
in
six
men
today
and
should
probably
go
to
the
top
of
our
priority
list.
F
Second
comment:
is
the
draft
isn't
both
both
important
and
difficult?
The
reason
it's
difficult,
hbh
as
it
is
today,
is
unimplementable,
because
the
hph
can
be
2k
long.
It
can
carry
a
thousand
different
options
in
it.
Obviously
nobody
can
implement
that.
So
you
need
to
be
able
to
you
need
to
scale
it
back.
But
the
question
is:
how
much
one
problem
is.
You
need
to
be
able
to
predict
the
future.
You
need
to
be
able
to
predict
future
requirements.
We
can't
see
the
future
to
make
it
worse.
We
can't
even
see
the
present.
F
We
don't
know
what
a
minimum
acceptable
requirement
would
be,
what
a
good
number
of
route
pro
a
good
number
of
forwarding
engines
would
be
able
to
process.
We
don't
know
if
you
know
one
two
and
three
or
three
options
is
right.
We
don't
know
quite
what
every
every
vendor,
what
what
a
reasonable
minimal
standard
would
be,
but
in
any
event,
important
work
plea.
Please
keep
going.
P
P
What
I
see
from
the
work
that
we
have
done
in
b6
ops
is
that
the
biggest
challenge
is
that
you
know
the
the
ultimate
length
of
the
extension
header
chain.
So
it
doesn't
really
matter
that
much
how
many
options
you
have
within
the
header
or
how
many
headers
you
actually
have.
But
the
point
is,
at
the
end
of
the
day,
what's
the
length
of
the
extension
header,
you
could
have,
for
example,
a
single
you
know
a
single
hope,
I
hope
options
heather,
but
which
has
a
single
option.
P
That
is
quite
long
and
that
would
still
be
a
problem.
So
if
one
wants
to
do
this
kind
of
thing,
like
you
know,
let's
say
limiting
or
constraining
the
extension
headers
in
a
way
that
you
know
might
help
them
survive
in
the
internet.
I
think
that
the
the
goal
or
what
one
should
be
targeting
is
to
target
the
extension
header
chain
length,
as
opposed
to
the
number
of
you
know,
powers
or
the
number
of
options
you
know
within
the
header.
I
Monica
and
and
fernando
I,
I
do
really
think
the
extension
the
the
solution
to
address
this
issue
hover
hub
issue
is
really
important,
but
it
seems
like
if
the
the
devices
will
drop
the
package
when
it
meets
the
hover
hub
header,
so
this
solution
cannot
work
as
well.
So
I
don't
see
how
this
mechanism
can
address
the
issue
and
also
I
I
agree
with
ron
bonika
that
we
do
not
know
how
many
options
we
will
need
in
the
future.
I
We
cannot
say
that
in
in
right
now,
so
I'm
not
really
sure
that
it
is
a
good
way
to
go,
but
I
would
suggest
that
if
a
operator
build
their
new
network,
it
would
possible
to
like
lease
requirements
that
every
device
should
support
hardware
processing
that
will
solve
the
address.
That's
that
was
not
the
issue.
I
I
think
yeah.
Thank
you.
K
So
does
he
need
a
problem
to
be
addressed?
This
hope,
I
hope
and
not
support
it
over
the
internet.
I
guess
it's
mainly
because
originally
probios
was
a
vector
for
dos,
so
it
was
shot
and
cut
at
the
edge.
But
beside
this
I
think,
even
if
the
program
is
solved,
hope
bio
in
over
the
internet
over
a
multi-ass
system
will
never
be
followed
and
executed
right.
We
know
that
this
sort
of
code
points,
for
instance,
are
only
applicable
within
one
domain.
K
A
K
N
N
R
So
I
think,
as
long
as
you
can
keep
that
envelope
down,
I
think
it's
like
a
positive
move
in
there,
but
and
and
going
back
to
eric's
comment
I'd
like
we
don't
know
if
this
is
going
to
get
routers
to
widely
implement
this
and
let's
pack
it
through
and
also
the
fernando's
point,
but
I
think
this
is
worth
trying
for
sure.
Thank
you.
S
Yes,
hi:
this
is
guillaume
with
verizon,
yes,
so
bob.
This
is
a
definitely
a
really
important
subject.
I
think
I
guess,
with
a
lot
of
other
applications,
wanting
to
be
able
to
use
h,
take
advantage
of
hph
and
at
this
point
hph
is
really
not
a
viable
option
to
be
used
really
for
any
type
of
application.
S
The
the
problem
is
definitely
multifaceted
and
and
many
layers
to
it.
I
think
one
of
the
big
big
layers
that
I
think
that
was
mentioned
is,
I
guess
you
know
the
christmas
tree
extension
header.
So
that's.
That
is
something
that
you
know.
That's
a
difficult
unit
variable
right
there,
the
other,
the
other
one.
S
That's
also
big,
is
chip
manufacturers
and
really
the
control
you
know
of
what
the
vendors
use
you
know,
whether
you
they
use
fixed
function,
a6
versus
npus,
which
have
better
processing
capabilities
and
that
that's
a
variable,
that's
kind
of
out
of
our
control
and
even
the
vendors
you
know,
they'll
pick
one
versus
the
other
and
and
then
you
run
into
issues
so
that
that's
another
major
variable.
Another
issue
that
exists
is
that
I
guess
getting
the
operators
really
to
understand.
S
But
you
have
like
an
underlay
overlay
and
there
are
many
cases
where
a
service
provider
core
network
may
may
actually
carry
the
internet
routing
table
either
in
the
global
table
or
in
a
vpn,
and
this
is
in
one
of
the
other
hph
drafts
that
we
we've
reviewed
on
the
with
on
v6
ops.
I'm
related
to
this
concept.
S
That
is
was
something
that
I'd
added
to
that
draft,
but
what
it
rolls
down
to
like,
if
you,
if
you
do
separate
it
out
and
you
have
your
global,
your
internet
traffic
carried
in
a
vpn,
your
underlay-
is
actually
not
impacted
by
the
by
the
by
the
flows
by
the
hp
adoption,
because
now
it's
in
the
payload.
So
that's
that's
another
caveat
that
exists.
So
operators
are
not
as
impacted
if
you
are
carrying
internet
traffic
and
an
mpls
and
an
overlay
versus
sitting
in
the
underlay.
S
If
you're,
actually
sitting
global
table
now,
you're
impacted
your
operator,
internal
network's
impacted
as
well
as
any
appearing
points
are
impacted.
You
know
end
to
end
you're
impacted
by
hbh
options.
So
that's
that's
another
impact
and
then
I
think,
with
what
what
bob
is
trying
to
do.
I
guess
limiting
the
a
speech
processing
by
reducing
the
number
of
limiting
number.
S
I
mean,
I
think,
that's
a
definitely
a
a
valid
attempt
to
try
to
help
the
processing
so
we're
not
punting
everything
to
the
to
the
control
plane
and
that
helping
with
that
separation
of
control,
plane
and
data
plane.
So
I
mean
I
think
that
is
definitely
helpful.
I
think
fine-tuning
and
trying
to
figure
out
a
way
to
stop
the
cycle
of
continuing
down
the
road
of
dropping
operators.
Dropping
all
hph
and
trying
to
you
know,
make
a
headway.
It
is.
S
I
I
I
think
this
issue
is
really
important
and
we
have
a
lot
of
notification:
innovation
based
on
hobby,
hub
extension,
header,
so
it
it
is
worth
to
discuss
the
solution
and
we
do
have
like
the
new
hobby
hub
extension
draft,
something
like
this
and
I
I
heard
some
other
solutions,
so
we
can
like
combine
together
to
discuss
how
to
address
this
issue
yeah.
Thank
you.
E
K
E
B
B
B
T
You
guys
hear
me
now
there
you
are,
please
go
ahead,
I'm
I'm
so
sorry
about
that.
I
just
want
to
say
I'm
with
an
enterprise,
and
a
lot
of
us
are
not
deploying
ipv6,
because
we
think
it
lacks
some
management
and
control
and
other
information
that
I
think
hop
by
hop
could
provide
very
nicely.
So
I
think
this
is
really
important
work
and
I
hope
it
continues.
T
U
U
B
P
Good
okay,
so
this
is
me
again
presenting
the
document
on
the
scope
of
unique
local
ipv6.
Unicast
addresses
next
slide.
Please,
before
getting
into
the
you
know
into
the
topic
itself,
let
me
discuss
a
little
bit
how
you
know
this.
I
you
know
how
this
issue
came
up.
You
know
I
was
doing
an
ipv6
training
course
and
I
was
essentially
explaining
the
ipv6
architecture
and
I
had
questions
asked
about
the
scope
of
addresses.
P
So
I
wasn't
that
sure.
So
I
checked
the
specs
regarding
you
know
how
the
scope
was
defined
in
the
you
know:
scope
addressing
architecture,
the
ipv6
address
in
architecture,
the
uls
specification,
and
then
I
found
that
there
were
conflicting
uses
of
the
definition
of
scope.
So
I
said:
okay!
Well,
it's
not
nice
that
you
know.
You
know
if
I
wanted
these
folks
to.
If
I
wanted
to
refer
these
folks
to
the
you
know,
actual
architecture
and
specifications
they
find
stuff.
That
is
conflicting.
So
that's
how
I
you
know
ended
up
rising
this.
P
P
Now,
if
you
wonder
okay,
why
should
I
care
about
this?
Or
should
I
care
about
this?
This
is
how
I
see
it.
The
let's
say
issue
that
we
have
is
that
if
you
try
to
understand
the
architecture
from
you
know
in
this
respect,
we
are
talking
about
the
scope
from
the
current
documents
that
we
have
you
know,
since
they
are,
you
know
conflicting,
that's
difficult,
so
you
know
among
people.
P
You
know
that
the
people
that
you
know
devote
a
lot
of
time
to
this
you
know
well,
might
be
conflicted
by
well.
We
kind
of
like
all
understand
what
we
mean,
even
if
we
don't
say
it,
but
you
know
from
forks
that
you'd
like
to
refer
to
the
specs,
you
have
to
explain.
Well,
the
terminology
is
not
exactly
very
precise.
P
If
you
wonder
well,
is
something
breaking
as
a
result
of
this?
No
certainly
not
I
mean
this
is
mostly
a
definition
thing
or
an
architectural
thing,
and
you
know.
Certainly,
definitions
will
not
cause
networks
to
break
so
there's
nothing
that
is
breaking
as
a
result
of
this.
Just
to
make
the
point
clear
now
there
are
practical
implications
of
this
and
we
will
discuss
one
of
them
because
there
are
cases
in
which
the
semantics
of
ipv6
addresses
matter
and
that's
where
definitions
kick
in
and
if
the
when.
P
P
M
P
And
well
so,
let's
talk
about
the
definition
of
scope,
so
this
is
what
we
have
in
4007.
Okay,
scope
is
defined
as
the
topological
span,
where
within
which
an
address
may
be
used
to
uniquely
identify
an
interface.
Okay,
that's
the
scope
and
global
scope.
As
a
result
of
that
means
that
you
know,
if
an
address
has
global
scope,
it
means
that
it
uniquely
identifies
the
address
the
interface
sorry
anywhere
in
the
internet.
Okay,
so
a
global
address
is
supposed
to
uniquely
identify
an
you
know,
an
interface
anywhere
on
the
internet
urls.
P
We
will
go
into
detail
later,
but
you
know
from
the
very
beginning.
You
know.
Obviously,
ulas
don't
conform
to
that.
Why?
Well,
because
you
are
randomizing
the
prefixes
and
you
know
if
we
happen
to
have
you
know
like
for
some
reason
randomly
we
ended
up,
selecting
the
same
prefix.
Obviously
the
resulting
addresses
will
not
uniquely
identify
an
interface
anywhere
in
the
internet.
P
P
Now,
when
discussing
you
know
the
scope
of
ulas,
normally
people
say:
oh
no,
but
that's
not
correct.
If
you
look
at
the
you
know
the
the
ula
specification
4193,
you
will
have
the
math
there
that
well,
okay,
it
doesn't
say
that
the
addresses
are
unique,
but
it
essentially
tells
you
that
the
probability
of
collision
is,
you
know,
really
low,
so
low
that
in
practice
you
can
claim
that
they
are
unique.
P
Now,
if
you
really
think
about
for
what
4193
is
saying,
what
it's
really
saying
is
if
you
grab
a
number
a
reduced
number
of
ula
based
networks-
and
you
interconnect
them,
then
this
is
what
the
probability
of
collision
will
be.
So
you
connect
only
two
networks
that
you
get.
You
know
blah
blah
blah.
You
connect
10
networks,
you
get
this
probability,
you
connect
10
000
networks
and
you
get
this
number
which
is
still
low.
P
P
That
would
be,
I
don't
know,
what's
the
number
10
million
100
million-
I
don't
know,
what's
the
number
now
when
you
do
the
when
you
compute
the
birthday
paradox
for
that
number,
then
now
the
probability
of
collisions
becomes
roughly
one,
so
you
are
guaranteed
that
you
will
actually
have
collisions
okay
now,
based
on
the
definition
that
we
had
before
for
for
what's
a
global
scope
address.
Well,
then
uls
can
obviously
not
be
global
scope,
because
if
you
have
almost
certainty
of
collisions,
then
you
cannot
claim
that
the
ula
uniquely
identifies
an
interface.
Okay,
next
slide.
P
Now
some
practical
implications
because
you
could
say:
okay
well,
the
definition
is
not
really
precise.
Well,
okay!
Now
this
is
an
interesting.
You
know
case
this
was
raised
by
you
know
brian,
so
credit
goes
for
him
to
you
know
to
to
spotting
this
one.
There's
a
library
in
python
we
take
with
processes,
ipe
addresses,
okay,
including
them.
It
processes,
ipv6
services
and
for
each
address
object.
It
has
some
attributes.
Okay.
P
So
if
you
know
you
set
some
address-
and
you
know
the
id
the
attributes
would
will
be
set
accordingly,
you
can
check
for
those
attributes.
So
there
are
two
attributes
which
are
defined
specified
by
the
library
as
follows:
is
private,
which
is
true.
If
the
address
is
allocated
for
private
networks
is
global,
which
is
true.
If
the
address
is
allocated
for
public
networks
and
what
happens
if
you
have
a
ula
well,
private
is
set
to
true
global
is
set
to
false.
P
Now
you
might
say:
okay!
Well,
these
guys
are
wrong.
That
might
be,
you
know
an
option,
but
when
you
look
at
the
actual
definition
of
you
know
the
actual
definition
of
scope
that
you
have,
you
cannot
really
blame
them
because
you
know
from
when
it
comes
to
the
definition
of
scope
and
global
scope
itself.
You
know,
ulas
cannot
be
global,
you
know
it
doesn't
utilize,
don't
comply
with
the
definition
of
global.
So
here
you
have
like
a
practical
case.
So
is
this
library
right
or
wrong?
P
I'd
say
that
you
know
from
a
conceptual
point
of
view.
They
are
right
if
you
ask
whether
they
are
compliant
with
the
specifications.
I
would
say
I
don't
know,
I
mean,
there's
a
conflict
in
the
specification,
so
it
they
they
my,
I
think
that
they
comply
with
4007,
because
this
is
you
know
what
I
you
interpret
the
scope
of
your
lace-to-be,
but
this
doesn't
comply
with,
let's
say
4291,
because
4291
lists
ulas
as
global
addresses.
P
P
You
cannot
really
tell
what
this
guy
should
do
with
the
library,
and
this
is
just
one
case.
So
this
is
one
case
spotted
by
brian
carpenter.
There
might
be
others,
okay,
I
don't
think
there
are
any,
but
you
know
you
do
have
also
macros.
You
know
that
you
can
use
in
the
you
know
when
you,
when
you
code
in
c,
to
check
some
things
as
far
as
remember,
there's
no
marker
that'll
check
for
this,
but
there
might
be
in
the
future
and
then
again
you
need
to
be
able
to
tell
you
know.
P
P
It
is
to
simply
you
know,
update
4291
in
the
part
that
says
just
specify
the
ela
prefix,
because
right
now
what
you
have
is
like
you
have
a
lot
of
listed
prefixes
and
what
4291
says
is
that
well
at
least
otherwise
noted
the
addresses
are
global
scope,
that's
what
they
expect
says
and
since
it
doesn't,
you
know,
have
anything
special
about
the
ula
prefix
by
default,
they're
global.
So
what
we
say
is
that
you
know
update
4291
in
the
sense
that
now
you
mark
the
ula
prefix
as
something
else.
P
What
you
want
to
call
it,
I
don't
care
about.
The
name
could
be
private
addresses
domain
local
addresses
whatever
I
mean
for
me,
the
name
doesn't
matter
like
no,
it's
for
the
working
group
to
to
select
that.
Then
you
know,
since
there
is
text
in
4193
that
essentially
claims
that
ulas
are
are
global
scope.
This
is
the
update
that
would
be
necessary.
You
know
in
in
the
day,
for
42.91
is
like
a
one-liner.
P
When
you
have
the
list
of
prefixes,
you
just
add
the
ula
prefix,
and
you
say
this
is
something
else
scope
something
else
address
type
whatever.
Whatever
name
you
want
to
use
for
4193,
there
is
a
bar
in
which
talks
about
ulas
being
global
scope,
so
the
fix
is
simple
and
is
the
text
that
we
have
here
essentially
saying
that,
whatever
term
that
we
use
to
define
the
scope
in
4291,
we
would
reuse
that
term.
P
Here,
for
example,
the
scope
of
these
addresses
is
local,
and
how
do
you
find
the
score
well
larger
than
link
local
and
smaller
than
global?
It's
something
in
between
you.
Don't
really
know
where
you
know
the
scope
ends,
because
you
can't
you
can't
and
the
all
the
other
thing
that
is
necessary
is
that
in
the
ayanna
ipv6
special
special
purpose
address
registry,
you
know
where
you
have
like
essentially
pointers
to
rfcs.
P
P
Slide
so
these
are
among
the
you
know,
the
possible
options.
First
option
is,
you
know,
adopt
this
document
as
a
working
group
item
in
the
hopes
of
working
or
trying
to
fix.
You
know
the
the
the
ambiguity,
for
example,
in
the
way
that
we
are
trying
to
you
know
to
fix
it
in
our
document,
but
there
are
other
options.
I
obviously
I
have
a
preference
for
the
first
one.
Another
option
would
be
okay.
Okay,
if
there
are
conflicting
definitions
like
you
could,
for
example,
we
could,
for
example,
do
a
4007
bs.
P
There
are
other
things
to
be
fixed
there
and
those
have
been.
You
know
discussed
on
the
mailing
list,
but
you
know
if
you
want
to
keep
the
same
definitions
for
ulas
like
claim
that
ulas
are
a
global,
you
know
you'd
end
up,
we
would
end
up,
you
know
changing
4007
and
we
would
you
know
come.
We
will
have
to
come
up
with
a
definition
of
global.
P
That,
I
would
say
would
be
quite
interesting,
so
you
know
yeah
I
mean
you
can
change
the
definition,
but
you
know
I
think
that
not
the
only
definition
that
would
you
know
fix
this
would
be
counterintuitive
to
what
you
expect.
You
know
global
scope
to
mean
then
obviously,
there's
always
the
option
of
do
nothing.
Okay,
I
personally
think
that
that's
not
you
know
attracted.
P
You
know
if
this
was
something
that
you
know
was
like.
Let's
say
conflicting
definition
in
I
in
ipv4
you
might
say:
okay,
well,
we
are
supposed
to
you
know,
get
rid
of.
You
know
ipv4.
Well,
at
least
we
have
the
hope
for
that,
but
but
in
the
case
of
ipv6
I
guess
we
all
expect
it
to
be
around
for
quite
some
time.
P
So
I
don't
think
that
of
you
know
having
something
that
is
conflicted
and
that
you
cannot
really
point
people
like
you
cannot
refer
people
to
to
actually
better
understand
that
the
the
topic
is,
like
you
know,
it's
an
you
know
an
acceptable
way
out
like
I
would
have
liked
it.
In
that
case,
where
I
had
the
discussion
to
point
to
to
tell
people
okay.
Well,
go
and
read
this
this
and
this
document
and
everything
will
be
clear
now,
if
I
had
done
so
well,
they
would
have
probably
came
up
with
this
like
well.
V
First
of
all,
I
kind
of
still
do
not
see
the
real
problems
there,
because
I
think
what
we're
talking
about
here
is
a
different
way
to
interpret
a
couple
of
rfc,
because
I
believe
the
uas
are
absolutely
unique
if
they
use
properties
the
same
way,
normal
global
addresses
are
uniquely
used
properly,
because
I
see
people
just
using
random
addresses
assigned
to
other
companies,
and
you
can
imagine
their
network
right
in
this
case.
We
cannot
call
any
address
you
need,
because
it's
actually
could
be
an
application.
V
If
someone
does
the
wrong
thing
right
also,
I
don't
ever
expect
to
get
10
000
network
fusion,
uls,
interconnected
right.
The
probability
of
being
unique
are
rather
high
in
the
expected
use
case.
I
don't
think
it's
a
real
problem
and
again
I
do
not
think
that
existence
of
one
library
we
probably
could
be
fixed
and,
as
discussed
in
the
chat
brian
actually
has
suggested
ways
to
fix.
It
should
be
a
reason
to
do
such
a
drastical
change,
and
now,
let's
explain
why.
I
think
that
we
shouldn't
change
the
scope.
V
If
we
change
the
scope,
we
will
get
a
problem
with
scoped
address
architecture.
When
I
use
my
ula
source
to
reach
the
global
destination
looks
like
I
cannot,
because
the
router
is
not
supposed
to
forward
it,
because
now
the
scope
of
the
source
address
will
be
less
than
the
scope
of
destination
and
the
packet
will
leave
the
zone.
W
P
P
You
you
wouldn't
even
interconnect
like
a
hundred
of
them
most
likely,
okay,
not
even
let
alone
ten
thousand.
What
I'm
saying
is
that
what
the
definition
says?
Okay
is
that
they
still
need
to
be.
If
it's
global
scope,
global
implies
the
whole
internet,
then
if
you
connect
them
or
not,
that's
a
different
question.
I
agree
with
you
that
you
wouldn't
interconnect
them,
but
the
definition
says
that
if
you
claim
that
something
is
global
scope,
whether
you
interconnect
them
or
not,
that's
a
different
issue.
P
You
could
block
them,
there's
a
lot
of
things
that
you
could
do,
but
what
the
definition
says
is
unique.
Internet-Wide
for
global
scope,
that's
one
of
that's
in
one
of
the
previous
slide
that
I
discussed
it
doesn't
say:
global
scope
is
unique
in
the
area
where
you
decide
to
use
it,
that's
different,
so
I
agree
with
what
you
say,
but
what
I'm?
What
I'm
saying
is
that
the
formal
definition
doesn't
agree
with
what
you're
saying
global
implies
the
whole
internet,
not
where
you
decide
to
use
it.
P
V
W
Fred
yeah,
thanks
for
the
presentation,
fernando,
I
just
wanted
to
point
out
that,
in
addition
to
llas
ulas
and
guas,
we
also
have
host
identity
tags
hits
from
rsc
7401
and
they
are
more
preferable
than
ulas
in
some
cases,
but
less
preferable
than
a
true
gua.
In
other
cases,
can
we
somehow
fit
that
into
the
hierarchy.
P
Well,
definitely,
you
know,
I
think
it
was
david
farmer
that
he
also
writes
it
not
just
the
case
that
you
rise,
but
even
other
ones.
So
definitely,
yes,
there
are
other
cases.
So
in
this,
this
is
the
one
that
you
know,
the
the
one
that
you
know
popped
up
the
the
issue,
but
I
do
agree
with
you
that
there
are
other
cases
that
you
know
most
likely
follow
the
same.
The
same.
A
Can
do
all
right,
so
thank
you,
so
I'm
I'm
one
of
the
authors
of
the
ula
spec,
so
I'm
speaking
in
that
regard,
I
actually
don't
agree
with
the
with
fernando's
proposal
here.
I
think
the
spec
is
actually
fairly
clear
about
the
the
level
of
uniqueness
and
it's
also
very
clear
about
the
way
ulas
are
intended
to
be
used
and
I'm
not
hearing
any
kind
of
operational
problem
that
this
is
causing.
A
I
think
this
is
I'm
not
sure
if
I
want
to
use
the
an
academic
issue,
but
I
don't
think
this
is
worth
the
benefit
I
think
of
changing.
Anything
here
is
very
small
and
it
potentially
also
does
harm
in
that
it's
going
to
maybe
cause
more
confusion
than
there
is
now
about
this
and
just
to
nitpick
a
little
bit.
A
P
B
P
Comment
is
that
so
this
is
the
this
slide
is
where
we,
you
know
they
have
the
the
definitions
that
we
are
referring
to.
So
I
agree
with
that.
You
say
that
okay,
within
the
scope
or
within
the
area,
not
let's
not
stop,
let's
not
say
scope,
because
that's
a
formal
definition,
if
you
say
within
the
area
that
I
would
end
up
using
the
ulas,
they
are
going
to
be
unique.
Agreed
fully
agree
with
that.
Now.
P
That's
what
I'm
referring
to
now,
if
you
say
okay,
this
is
you
know,
let's
say
an
academic
definition.
I
mean
in
a
way.
Yes,
but
you
know,
architecture
is
academic.
If
you
want,
you
know
doing,
an
architectural
document
is
academic
and
then
there
are
implications
like
there's
the
python
library
example
that
I
mentioned
is
it
okay?
Should
them
fix
it,
and
why.
T
Please
go
ahead:
okay,
thank
you,
michael
ackerman,
again
and
again
from
the
enterprises
perspective,
we're
wrestling
with
deploying
of
ipv6.
Now
one
of
our
issues
is:
what
do
we
do
for
situations
where
we
currently
use
1918
dresses
for
various
reasons,
and
we
think
that
euless
could
be
a
good
answer
there,
but
quite
frankly,
we
don't
understand
them
and
what
the
scope
is
and,
like
one
of
fernando's
slides
said,
we
come
out
somewhere
between
link
local
and
the
entire
internet.
T
G
A
virtual
frog
yeah.
I
just
wanted
to
say
that
the
the
python
library
goes
back
to,
I
think
some
very
early
ip
address
library
work
around
2008
or
nine
at
google
by
various
folks.
So
it's
pretty,
you
know
some
of
that
stuff's,
pretty
old
and
also
you
know
brian
carpenter's
draft
about
what
does
global
mean
talks
about
some
of
this
stuff.
G
But
I
think
you
know
the
difference
between
global,
addressing
and
global
routing
is
is
a
key
realization
and
that
ip
address
library
did
not
at
the
time
take
any
of
that
into
consideration.
It
was,
you
know,
meant
simply
to
try
to
disambiguate,
clearly
global
addresses
from
other
things,
so
and
and
also
the
the
temptation
to
try
to
map
ulas
onto
rfc.
1918
may
have
been
present
and
it's
you
know
that
that
mapping
is
imprecise,
so.