►
From YouTube: IETF103-6MAN-20181106-1350
Description
6MAN meeting session at IETF103
2018/11/06 1350
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
A
A
B
Okay,
so
to
quickly
go
through
the
document
status.
Since
the
last
meeting
we've
published
one
RFC
that
was
actually
mine,
RFC
84,
25
short
lists,
we've
done
ever
I
think
we
have
one
document
in
the
RFC
editor
queue.
It's
the
node
requirements
document
so
expect
that
to
be
out
quite
soon,
we
have
two
long-running
working
last
calls
it's
a
segment
routing
header
document
since
end
of
March.
That
has
a
session
following
this
slot.
B
We
have
two
active
working
group
documents,
but
as
far
as
I'm
aware,
nothing
has
happened
with
these
two
since
the
last
IGF,
which
was
in
control
yeah
and
the
other
news
bobbin
steering,
has
managed
to
publish
the
original
specification
almost
published.
Sorry,
yes,
it
is
in
the
RFC.
Editor
queue
right.
Yes,
so
now
you
can
enjoy
how
the
original
proposal
for
ipv6
started.
It's
it
fresh
yeah.
C
So
it
just
went
through
the
iesg
conflict
review
and
it
was
approved
like
couple
of
weeks
ago,
Bob
so
yeah
and
yeah.
It's
publications,
people
are
saying
like
why
doesn't
it
have
like
I
on
a
consideration
section
and
its
security,
consideration,
everything
and
say?
Okay.
This
is
a
historic
thing.
How
things
looked
like
at
the
time
so
yeah
yeah,
yeah.
A
I
can
add
so
there
was
a
meeting
where
it
and
some
other
things
were
discussed,
and
there
was
the
big
debate
was
a
dress
size
and
are
fixed
versus
variable
length.
So
the
the
wisdom
of
the
community
of
the
of
the
committee
was
to
not
go
a
variable
but
make
what
was
then
called
simple
IP
double
the
dress
size
to
what
we
have
now.
B
C
So
the
this
Geoff
has
like
being
revised
multiple
times,
but
I
personally,
don't
think
it
has
address
all
the
issues
that
came
up
in
six-man
review.
So
I
told
the
authors
that,
like
you
know,
they
have
to
like
just
close
the
loop
on
all
the
reviews
that
came
in
in
six-man
and
also
close
the
loop
and
IP
wave
about
the
changes
they
made
regarding
that.
C
So
once
it
finishes
up
in
IP,
wave
I'll
bring
it
back
to
six
months,
so
we
can
take
a
look
at
it,
at
least
like
I,
think,
there's
some
of
Lorenzo
stuff
and
some
of
Brian
stuff.
That's
left
out
from
there
and
Eric
nor
Marc
Senter
review
straight
into
IP
wave
as
well,
which
has
some
signal
relative
issue,
so
I
think
like
once
all
those
are
covered,
I'll
bring
it
back
here.
Yep.
B
And
then
there's
been
a
question
from
from
the
spring
chairs
on
to
spring
drafts
that
effects
the
IP
six
source,
routing
header,
it's
the
operations,
administration
and
maintenance
in
segment;
routing
draft.
That's
on
the
agenda
today
and
it's
the
service
programming
with
segment
reaching
drafts,
and
it's
some
discussion
between
80s
and
the
chairs
where
those
documents
should
belong.
If
anyone
have
any
opinions,
please
come
to
the
mic
so
far.
B
B
D
B
Is
now
you
know
if
we
can?
We
know
this
discussion
on
the
mailing
list
as
well.
We
will
see
at
least
that's
opened
at
a
moment.
Then
I
think
we're
not.
We
haven't
been
very
good
at
updating
milestones,
but
these
are
the
previous
ones.
Where
were
we
we're
done
so
we
invented
some
new
ones.
You
know,
should
we
do
more
documents,
ooh
internet
standard?
We
have
this
work
going
on
now
on
on
path.
Mtu,
do
you
want?
B
B
This
week,
mahadji
has
a
little
five-minute
lightning
talk
after
this
session
on
v6
security
and
privacy
that
someone's
written
a
paper
or
two
about
there's
sort
of
correlated
imputed
set
of
discussions
in
the
TSV
w
group
tomorrow,
wednesday
and
this
spring
as
well
on
Wednesday,
which
might
be
of
interest
other
things,
we've
thought
about
a
little
bit.
There
is
some
discussion
about
using
github
to
improve.
You
know
document
process,
make
it
much
clearer
when
you
make
document
changes,
so
those
attract
and
you
do
pull
requests.
B
B
Separate
rough
on
that
tomorrow
call
the
working
groups
using
each
app,
both
I
think
yes
Wednesday,
and
we
could
also
know
that
our
incoming
rate
is
very
high,
but
in
v6
ops,
they're
doing
this,
you
know
review
a
document
per
week,
just
encourage
or
in
focus
the
working
group
a
bit
and
that's
something
we
could
do
as
well.
If
it
turned
out
that
we
had
lots
of
drafts
to
to
review
okay.
So
that's
this
one.
Any
comments
on
that.
B
F
Okay,
if
it
remains
poor,
let
me
know:
I'll
kill
the
camera
okay,
so
good
morning,
the
afternoon
evening,
everyone
we
have
a
lot
of
participants
online
and
looks
like
a
good
number
in
the
room.
My
name
is
Darren
Dukes
and
I'm.
Talking
about
Sigma
coding,
header
division,
16
of
the
draft
is
sitting
waiting
to
get
authorized
to
get
to
get
published.
Hopefully
that
happens
shortly,
but
we'll
go
over
the
changes
between
14
and
16
and
what
progress
has
been
made
since
ITF
one
on
two
and
what
are
outstanding
items?
F
Luck
and
I'm
gonna
get
you
to
advance
the
slides
guys.
Cuz
I,
don't
see
a
advance
button
on
my
screen,
so
next
slide.
Good,
quick,
thank
you
to
everyone,
who's
contributing
on
the
list.
Most
recently,
there's
been
it's
doing
a
good
level
of
discussion,
so
thang
the
folks
are
doing
that
and
more
discussion
is
welcome.
So
anyone
with
some
thoughts
please
go
ahead
and
use
that
use
the
list
to
get
those
out.
Next
line
for
an
agenda
we'll
go
through.
F
What's
happened
in
the
last
call
really
quickly
the
changes
from
1416
the
open
issues
that
we
still
have
and
the
next
steps,
as
well
as
a
bit
of
a
timeline,
is
to
when
we
should
be
finishing
up
the
open
issues.
Next,
the
last
call
updates
that
quickly
we
have
47
open
issues,
we've
closed
up,
39
of
them,
I'll
work
with
Bob,
and
only
this
weekend
next
to
make
sure
the
ones
that
are
closed
in
1416
or
or
correctly
marked
I,
don't
think
they
are
yet,
but
we'll
get
that
done
pretty
quickly.
F
We
have
what
I
believe
are
eight
remaining
issues
open
and
we'll
talk
about.
Those
today
does
some
extent
we'll
have
time
for
questions
at
the
end.
Also
focus
it's
like
that.
Next,
next,
okay,
an
IETF
102.
We
had
a
number
of
next
steps.
We
had
tags
that
needed
work.
We
have
teal
bees
that
need
the
work
management
data
playing
section
either
their
data
model
section
that
needed
work.
Those
are
not
done
yet.
F
The
section
that
did
get
attention
between
IEM,
102
and
103,
which
took
most
of
our
time,
was
rewriting
security
section
and
separating
the
processing
to
make
my
page
Mac
definition.
Eventually.
Why
and
how
segment
list
circuits
sure
are
secured
within
the
deployment
model,
examples
that
are
provided
a
next
on
the
Ange
Mac
side
other
than
consolidating
the
text.
Revision
16
simply
has
a
additional
verification
of
checking
that
the
current
segment,
the
element
at
segment
clip
segment
last,
is
equal
to
the
destination
address
in
Paquette.
F
F
That's
our
source,
though
it's
not
directly
connected
to
be
asserted.
So
I
had
some
business
question
on
that
on
the
list
too
and
I.
Think
yeah
I
think
that's
pretty
much
closed.
Now,
with
revision.
16
of
the
doctrine,
that's
like
the
security
consideration
section
was
rewritten
the
primarily
focuses
on
security
considerations
for
the
deployment
models
that
are
in
the
draft.
Now
we
looked
at
source
running
attacks
in
1595
identified
where
they're
applicable
aren't
or
not
within
the
SR
domain,
so
there's
Tex.
F
It
clearly
specifies
that
now
we
looked
at
service
theft
at
apology,
disclosure
for
SR
source
nodes,
both
side
being
that's
our
domain
in
particular,
and
call
it
the
fact
that
there's
the
ability
to
have
other
services
after
our
technology
exclosure
in
some
use
cases
and
in
other
use
cases
where
that
def,
clear
disclosure
may
not
be
may
not
be
a
concern.
So
so
the
graph
highlights
where
the
risk
areas
are
in
the
ICMP
generation.
F
F
The
several
QA
questions
that
came
upon
the
lists
from
folks
Chang
and
run
and
Joe
thanks
guys
for
bringing
up
those
items.
Those
are
wrapped
up
in
revision.
16
next
slide,
so
that
leaves
the
set
of
open
issues.
Next,
the
set
of
issues
Adrian
that
we've
gone
over
this
I
didn't
update
and
revision
15
that
I
still
overworking
with
updates
on,
but
we've
got
closure
recorded
in
the
document
at
least
separate
documents
with
a
drain
on
those,
so
I
will
go
to
able
to
group
that
one
next
slide.
F
G
G
They
somehow
have
to
know
at
the
TCP
level
to
use
the
saves
as
the
addresses
rather
than
the
addresses,
and
they
have
to
two
different
have
support
for
both
putting
SIDS
in
the
base
pan
putting
the
SR
header
in
the
base
packet
or
putting
an
encapsulation.
If
we
always
used
encapsulation
we'd,
remove
complexity,
we'd
remove
questions
and
it
would
get
simpler,
and
this
I'd
like
to
know
your
opinion
on
the
value,
but
then
I
think
it's
really
for
the
working
group
to
say.
Maybe
we
should
just
go
with
one
instead
of
two
right.
F
So,
as
far
as
the
the
first
part
of
your
statement,
you
said
the
TCP
layer
needs
to
know
to
use
a
CID
or
a
destination
address
when
a
hostess
is
communicating
with
other
hosts.
In
the
example,
between
eight
and
nine
that
we
used
hosts
are
always
talking
with
destination
addresses.
So
if
I'm
going
to
Jill
halfrek
comm
I
use
your
destination
investigator.
G
If
I
can
amplify,
if
you
do
it
ending
to
a
nine
and
it
gets
a
CID
list
and
that's
it
has
an
SR
policy
and
it
wants
to
apply
it
I
get
all
that
if
it
uses
the
encapsulation
mode,
it
works
exactly
the
way
you
just
said
it.
The
underlying
packet
is
a
packet
from
a
eight
to
a
nine
there's,
an
encapsulation
with
SIDS
and
everything
works.
Fine.
G
G
F
G
F
They
so
I
understand
that
I
think
that
I
mean
if
you
look
at
the
Linux
implementation.
For
example,
I'm
talking
to
a
destination
I
have
a
signal
list.
I
apply
the
segment
list.
It
seems
very
straightforward
now
whether
I
want
to
if
it
seems
very
straightforward
when
you
look
at
the
implementation.
So
maybe
we
need
to
continue
that
in
a
separate
thread
on
the
list
and
maybe
get
some
more
input
on
it
from
other
folks.
What
do
you
think
Joel?
That's.
B
H
B
A
So
working
group
last
call
started
on
the
6th
of
September.
There
were
many
emails
decided
not
to
count.
There
was
also
as
part
of
that
request
for
implementation,
and
we
now
have
one
implementation
based
on
that.
I
want
to
thank
to
Lee
Howard,
particularly
for
his
detailed
comments
on
the
draft
many
comments
and
basically
for
everyone
else's
feedback.
I.
Think
it's
improving
it.
A
D
A
Noted
edit
some
text
about
the
state
of
the
flag
bits
and
the
RA,
and
this
got
extended
in
the
next
draft
as
well.
You
know
I
particularly
noted
that,
since
we
did
the
RFC
that
added
more
flag
bits
there
haven't
been
any
re
bits
assigned
doesn't
seem
like
they're
getting
used
up
quickly,
clarified
text
about
logging,
configuration
errors
in
Section,
six
editorial
changes
and
then
a
lot
of
changes
in
the
draft
that
was
just
published
on
Monday.
When
the
repository
opened
up,
we
had
a
text
about
explaining
better.
A
We
had
a
text
that
administrators
must
only
use
this
mechanism
if
they
are
certain
that
the
link
is
ipv6.
Only
we
made
it
stronger
than
previously
was
they
should
we
added
ARP
to
section
four
that
you
know
for
the
about
the
which
protocols
this
flag
applies
to
previously
set
IP,
but
it
also
really
applies
to
our
PA's.
Well,
we
renamed
the
flag
from
six
to
s.
The
other
flags
are
given
alpha
numeric
labels,
so
it's
I
think
that'll
be
less
confusing,
I
sort
of
like
six,
but
this
is
probably
better.
A
We
added
pointers
in
the
document
to
the
section
of
neighbor
I
think
it's
neighbor
discovery
where
it
talks
about
which
which
flags
get
validated
and
then
so.
That
also
resulted
in
essentially
we're
adding
that
if
you
implement
this,
you
should
also
check
the
state
in
Ras
or
a
consistency
and
then
log
that
if
you,
if
there's
a
problem,
we
change
section
seven
from
should
not
to
must
not.
We
had
an
appendix
on
implementations
and
testing
and
then
many
small
clarifications
based
on
the
list.
Discussion
and
editorial
changes,
I
think
it's
it.
A
A
In
any
case,
it's
probably
the
middle
of
the
night,
so
it
was,
it
didn't,
take
a
lot
of
lines
of
code.
He
tested
it
with
FreeBSD
routers
Ruby.
Yes,
he
hosts
on
Ethernet
and
Wi-Fi
and
with
Windows
10
and
OSX
clients.
So
and
then
there
was
also
a
test
of
using
a
tool
called
scrappie
to
sort
of
send
our
age
with
the
bit
set
and
see
what
happens
to
legacy
hosts,
and
so
the
results
of
this
is
that
you
know
I
think
in
the
freebsd
implementation.
A
A
A
You
know
this
is
to
inform
hosts
that
to
not
not
tried,
not
use
before
so
there's
still
there's
an
incremental
benefit.
Even
if
you
have
layer
two
filters,
but
not
every
like
my
home
network
at
home
does
not
have
I,
have
no
ability
to
filter
at
layer
two
are
it
was
asserted
that
you
know
it's
not
needed,
but
could
host
can
discover
the
lack
of
v4
service
anyway
and
I.
A
Think
it's
hard
to
make
this
reliable
and
the
fact
of
using
before
to
discover
before
services
may
cause
other
hosts
to
think
there
is
before
so
I
think
this
is.
You
know
this
is
a
better
mechanisms.
It's
a
signal
from
an
administrator
that
the
link
is
ipv6
only
good
next
one
was
could
be
used
by
a
you
know.
We
could
build
a
DHCP
v4
mechanism,
but
of
course,
if
the
wrap,
if
there
are
no
beef
for
services,
then
this
is
hard
to
do.
This
would
require
having
v4
services.
A
Then
you
know
it
could
be
done
by
a
management
protocol
or
DHCP
v6.
You
know,
and
the
use
of
management
protocols
is
certainly
used
in
a
lot
of
you
know:
enterprise
environments,
but
it's
not
used
at
all
environments.
It's
not
used
on
bring
your
own
device
environment
in
managed
networks.
You
know
we
have
lots
of
unmanaged
links.
An
RA
is
the
only
universal
mechanism
that
gets
to
all
these
v6
notes.
A
A
If
you
have
a
reason
to
do
something
else,
you
can
still
do
that,
but
in
I
think
in
the
mature
most
cases
receiving
the
flag
will
cause
the
host
to
not
use
before
anymore
and
that's
the
intent
and
it
next
one
was-
might
cause
Interop
issues
among
the
four
hosts.
We
don't
see
this
as
an
issue.
The
administrator
has
decided
to
decide
it
that
this
is
going
to
be
an
ipv6.
A
Only
link
so
the
fact
that
before
will
break,
is
sort
of
a
feature,
not
a
problem,
so
the
authors
think
this
is
ready
to
advance
obviously
depends
on
the
working
group.
The
implementation
experience
shows
that
it's
feasible
and
it
doesn't
disrupt
legacy,
ipv6,
implementations
and
so
the
you
know,
question
is
what
are
the
next
steps
and
I
think
that's
where
Olli
gets
well
come
to
the
mic
and
then
Olli
gets
the
talk.
I
Liddy
I
am
don't
have
a
problem
with
this
sexually
good
and,
unlike
most
people
here,
I
do
have
like
some
submits.
So
when
a
default
route
a
lifetime
goes
to
zero.
You
enable
IP
before
that
seems
weird
in
the
sense
that
it
is
normal
for
the
route
of
lifetime
to
go
to
zero
if
the
route
of
loses
upstream
connectivity
and
so
now
suddenly
you've
got
all
these
hosts.
Like
yay
turn.
A
I
We
add
at
that
part,
but
I
can
try
to
think
of
it.
It
also
says
I'm,
gonna
replay
a
colleague
that
a
colleagues
comment
to
me.
Have
you
learned
nothing
from
my
P
before
and
the
reason
I
say
this?
Is
it
says
that
this
is
the
only
version
of
IP
on
the
link
and
like
what
about
IP,
v10
or
whatever?
It
is
like.
I
That's
like
let's
say
that
no
lower
numbered
versions
of
my
P
on
this
thing,
current
use
or
something
right,
because
you
can
bet
your
bottom
dollar
that
like
when,
when
we
actually
deprecated
ipv6
I,
know
we'll
all
be
retired,
but
you
know
that
flag
is
gonna,
be
set
to
one
and
it
won't
be
able
to
pass
you.
You
won't
be
able
to
change
it
anymore
because
it's
gonna
be
baked
into
the
implementation.
Well,.
I
Finally,
I
think
the
nature
of
currently
the
nature
of
ipv6
provision
is
that
it's,
if
you
follow
the
RFC,
it's
always
slower
than
ipv4,
and
so
you
can
avoid
pretty
much
all
of
the
attacks.
It's
like.
Oh,
my
god,
I've
gotta,
before
only
network
and
I'm
gonna,
send
an
RA
and
everything
stops
working.
You
can
just
say:
look
if
before
configuration
has
already
succeeded
and
it's
been
validated
to
work,
don't
turn
anything
off.
I
Even
if
you
get
a
flag
set
to
one
and
I
think
that's
really
going
to
avoid
pretty
much
all
the
attacks
and
realistically,
if
you
got
an
address
and
it's
working,
you
probably
don't
want
to
do
you
probably
won't
run,
don't
want
to
stop
using
it
right
like
what
are
you
gonna
prefer
nat
64
over
native
IP
before
that
seems
silly
so,
and
I
think
that
will
really
address
a
lot
of
the
attacks.
Okay,.
J
Okay,
Eric
link
just
I
mean
I,
like
the
draft
as
well.
There
is
one
point
in
the
introduction
where
you
cite
a
lot
of
benefits
of
this
flag
and
the
last
one
reads
on
an
ipv6:
only
link
ipv4
might
be
used
for
measures
purposes
and
by
pass
unnoticed,
maybe
unnoticed
by
ipv6.
Only
monitoring,
which
is
true,
the
sentence
is
true,
but
it's
not
a
real
benefit
because,
but
it
does
not
prevent
somebody.
Oh
start
still
using
a
PV
fault
to
attack
ipv4
or
some.
A
A
F
C
Suresh
krisshnan
ad
hat
off,
like
I,
like
the
vest
okay
ad
hat
on
now.
Iii,
don't
want
this
to
go
down
the
same
path
as
like
M&O
bits
because,
like
the
way
like
it's
things
are
shaping
up
right
like
especially
what
Lorenzo
said
right,
like
kind
of
like
set
off
my
spidey
sense
a
little
bit
right.
So
if
the
host
has
started
this
before
stack,
it's
the
same
thing
that
oh,
if
the
host
has
already
started,
doing
dhcpv6
and
then
them
embarrassed
not
set,
then
keep
doing
your
thing
right
so
like
it.
C
It
all
looks
unlike
us
to
me.
So
we
are
trying.
Are
we
trying
to
come
three
values
into
one
bit
right?
That's
always
the
question
I
had
in
my
head
right
like
for
EM
and
all
bets
like
we
are
trying
to
do
a
little
bit
more
so
I
think
one
of
the
issues
is
like
you
know.
We
don't
have
a
clear
consensus
on
what
horse
need
to
do
with
the
slide,
so
that
that's
kind
of
what
I
understood
from
the
discussion
right.
C
C
The
hard
part
right
like
I,
saw
an
implementation,
but
like
once,
we
try
to
standardize
like
what
a
horse
needs
to
do
and
then
it's
gonna
be
difficult
right,
but
maybe
we,
the
working
group,
decides
not
to
do
it,
but
I
think
like
we
need
to
be
a
bit
careful
there,
like
you
know
if
we
hand
wave
that
part
like
it's
probably
not
gonna
work
very
well.
So
how
not.
C
Try
to
be
a
bit
more
clear
on
the
horse.
Behavior,
like
you
know
what
what
is
expected
like
and
I
I
do
see
like
shoots
in
there
right
and
maybe
a
little
bit
more
description.
Unlike
what
happens,
what
doesn't
happen
and
if
you
try
to
take
like
Lorenzo's
suggestion
right,
like
you
know
what
you
would
right
there
right
like.
So,
oh,
if
you
already
Saturday
v4
stack
continued
to
do
it
or
not
like
that.
C
That
part
is
not
clear
to
me
right,
like
you
know
how
that
would
actually
work,
and
we
have
seen
similar
issues
like
multiple
times.
We've
seen
this
in
DNA
as
well
right
in
DNA
like
a
host
router
thumbs
up,
then
another
order
comes
up,
and
then
you
had
to
figure
out
like
what
set
of
prefixes
in
you
to
use.
So
I
think
this
is
like
a
common
issue.
A
We
can
and
I'm
not
sure
I'm
comfortable
proposing,
but
I
mean
we
could
say
you
must
do
this.
If
that
but
I
don't
you
know,
I,
don't
know
that
we
can
force
right,
I,
think
it's
a
you
figuring
out
the
right
word
and
what
we
expect
and
what
we
allow
I
think
is,
is
sort
of
hard,
but
I
still
find
that
you
know
I
think
in
in
cases
where
the
administrator
wants
to
run
ipv6.
C
K
It's
like
my
dear
ibrehem,
so
say
this
is
six
man.
I
would
want
to
define
this
flag
and
I.
Don't
wanna
I,
don't
wanna
rathole
on
exactly
what
the
host
does
and
it'll
be
a
lot.
I
think
this
should
is
perfect.
It's
up
to
the
you
know,
implementer
of
the
system
to
decide.
You
know
in
each
case
and
so
on.
We
can
have
a
document
in
three
years
with
best
common
practice
on
how
to
handle
this
people
test
it,
and
they
say
we
have
this
use
case
over
that
printer
blah
blah
blah.
K
You
know
we
let
people
play
with
it.
Let
people
find
out
what
works
and
what
doesn't
and
then
we
write
that
document,
because
otherwise
we'll
sit
here
in
two
years
and
we
will
have
nothing.
So
this
is
a
treat
this
as
a
signal
from
data
administrator.
Hey.
They
don't
think
you
should
run
before
here
and
then,
if
people
say
oh
yeah,
I'm
gonna
put
it
as
one
thing
into
my
four
different
signals
that
I'm
using
that's
fine
right,
write
a
document
in
your
three
years,
so
P
six.
C
L
K
C
I
The
enema
of
the
emaan
obits
were
controversial
because
people
are
have
been
fighting
for
fifteen
years
on
what
to
do
right
and
and
that
fight
is
ongoing.
That's
well
and
healthy,
right
and
so
the
reason
the
M&O
bits
are
supposed
to
maybe
tell
you
what
you're
supposed
to
do
when
people
don't
agree
on
what
to
do,
and
that's
why
the
M&O
bits
are
controversial.
I
think
just
wanted
to
say
that
and
yeah.
When
people
don't
agree,
they
don't
agree,
doesn't
matter
what
you
write
right.
I
As
an
implementer
I'm
fine
with
this,
actually
because
what
it
does
is
like
I
can
do
something
really
dumb
immediately
and
then
I
can
be
something
a
little
bit
less
dumb
tomorrow
and
over
time.
We
can
turn
the
crank
on
how
much
this
actually
disables
things
in
right.
What
I'm
gonna
do
at
the
moment
is
basically
like.
Okay,
if
it's
been
whatever
ten
seconds
left
on
the
clock,
I've
got
v6
done
before
you
know.
Maybe
I'm
gonna
set
the
DHB
before
it.
You
know
retransmit
interval
to
a
half
an
hour
instead
of
two
minutes.
I
I
can
save
some
battery,
like
that.
It's
super
conservative,
but
it's
pretty
much
gonna
work
all
the
time.
I
do
it
like
it.
You
know
20
or
whatever
ten
times
in
the
first
minute
and
then
five
minutes
and
then
like
I've,
been
set
up
backing
off
at
two
minutes,
I
back
off
a
half
an
hour
and
then
later
on,
we
can
I,
don't
think
and-
and
the
implementations
are
all
so
different
from
each
other.
I
That
I
think
that
we're
trying
to
write
it
down
here
is
gonna,
create
more
of
a
hornet's
nest
and
and
we're
not
gonna,
have
a
one-size-fits-all
solution
and
I
think
a
hint
is
fine
and
specifically
for
the
before
thing,
I
think
when
you
have
a
working
before
address,
you
should
just
say
for
that.
That
I
think
is
pretty
clear.
If
dhp
before
has
already
succeeded,
this
flag
is
void,
and
that
seems
clear
to
me
if
but
right
I
mean.
A
Because
what
we
see
when
we,
you
know
the
thing
that
started
this
was
when
we
did
the
v6
only
thing
of
several
IETF
meetings
ago,
and
we
saw
that,
while
there
were
no
addresses
assigned
with
DHCP
before
there
was
all
the
link
layer,
link,
local
stuff
happening
and
thatthat
sort
of
what
we
intended
to
stop.
So
I
do
agree
that
if
you
know,
if
you
can
get
an
address
with
DHCP
v4,
then
this
flag
probably
isn't
wasn't
set
correctly.
L
B
C
Like
some
of
the
criticism
that
came
in
right,
like
so
I
mean
my
problem
is
that
there
is
no
obvious
consensus
on
my
mailing
list
right
and
the
biggest
concern
I
have
is
right,
like
one
of
them
came
from
like
a
big
host
implementer
and
that's
concerns
me
a
little
bit
right
and
that's
I
want
to
see
if
you
can
address
it.
But
if
it's
not
it's
not
as
rough
consensus
right.
So
it's
but
I
will
try.
If
there's
something
it
can
be,
I
can
probably
like
go.
C
A
C
C
Bob,
like
specifically
I,
was
talking
about
the
one
that
saturd
it
all
kind
of
thing
right
like
before
how
this
happened.
I
was
like
oh
I'm,
really
opposed
to
it.
That's
all
I
was
trying
to
write
like
fake
and
the
beginning
of
the
presentation,
but
like
yeah.
That
is
really
the
point
of
on
earth
address.
K
B
Had
we
could
do
some
consensus,
calls
I,
don't
know
so
the
you
know
one
question
I
had
was:
do
we
want
to
do
this
or
not
I
mean
that's
one
question
we
could
ask,
and
if
the
answer
to
that
was
yes,
we
could
also
do
a
consensus.
Call
here
on.
Should
the
flag
be
prescriptive
ie,
so
it's
the
host
behavior
is
testable
and
you
can.
B
K
So
I
one
of
the
hosts,
you
know
a
large
host
implementers
and
the
way
I
thought
I
told
him
that
I
would
like
them
to
go
up
and
say
this
and
solve,
but
he
was
basically
I
got
the
feeling
from
them
that
they
they
wanted
the
hint,
and
that
was
fine
and
it
would
be
part
of
heuristics
I,
think
it
very
similar
to
what
Lorenzo
said
was
the
feedback
from
others
as
well.
Okay,.
M
K
K
K
Right
right,
but
okay,
so
I
would
say
if
someone
is
going
to
use
that
should
and
say
that
the
host
is
doing
the
wrong
thing
when
it
doesn't
immediate.
The
hotplate
turn
off
v4
I
think
they're
gonna
lose
that
there
is
no
way
with
you
know
we're
not
the
protocol
police
anyway.
That's
not
gonna
happen.
So
if
the
expectation
is
if
we
should
have
shoot
in
there
and
that
most
host
acts
good,
you
should
behave.
Hotplate
turn
everything
on
immediately
resolution.
All
that's
not
gonna
happen.
I
did
that's
what
I.
K
I
Life
as
an
implementer
is
not
knowing
what
to
do
like
you
know
you
deal
with
it
like
that's
what
you
do
you
start
with
an
empty
editor.
I
was
like
okay.
What
do
I
write
today
and
it's
like
okay?
Well,
the
standard
says
this-
is
that
gonna
work,
yeah
kind
of
probably
not.
Let's
do
something
different
so
for
what
it's
worth,
I
think.
I
We're
here
to
make
sure
that
when,
when
you
do
something-
and
you
need
to
interpret
with
someone
else-
that's
gonna
work
as
expected
and
I
think
we're
misstating
we're,
definitely
overstating
the
the
the
level
of
requirement
that
I
should
poses.
It
says
you
know
the
implications
have
to
be
carefully
considered
before
doing
something
different
right
and
if
you
have
a
good
reason,
like
hey
I,
discovered
an
mdns
thing
on
this
link,
that's
before
only
I
better
keep
using
before
otherwise
I
can't
talk
to
it.
That's
a
valid
reason.
K
And
Michael
everything
and
what
Lorenzo
said
is
that's
my
take
on
it.
That's
what's
going
to
happen
anyway.
We,
regardless,
if
we
put
a
muster
even
if
we
were,
got
consensus
from
us,
that's
what
would
happen
anyway,
so
we
might
just
have
a
show.
Then
everybody
realized
that
yes,
there
will
be
now
be
a
time
where
people
will
be
it's
like
the
whole
happy
eyeballs,
timer
evolution.
People
started
with
you
know:
okay,
I'm,
not
gonna,
give
any
protocol
any
headway,
and
then
it's
like,
oh
that
yeah
this
seems
to
work.
K
B
K
I
actually
think
that,
if,
if
we,
if
we
point
out
that
this
should
gives
a
lot
of
leeway
to
host
implementers
I
do
think
we
have
consensus
because,
okay,
there
are
some
people
who
really
want
to
prescribe
this.
They
are
never
going
to
get
that
document
through
if
they
keep
insisting
that
the
question
is
what
do
they
want?
It
is
better
for
it
to
have
the
flag
over
time
and
it's
it's
a
hint
or
no
flag
at
all.
A
K
K
Think
six
months
should
define
what
goes
on
the
wire
and
not
try
to
specify
host
behavior
when
it
comes
to
these
situations,
I
mean
if
it's
we're
talking
about
working
in
drop
here,
we're
talking
about
turning
off
a
protocol,
and
this
is
an
optimization,
so
we
should
not
be
prescriptive
in
this
case.
It
is
my
opinion.
I
We're
really
arguing
about
this,
then
I.
Think
if
you
water
down
the
text,
so
it's
actually
really
a
hint
that
makes
it
easier
to
gain
consensus.
I
think,
because
host
implementers
are
always
going
to
claim
leeway
to
do
what
they
think
they
have
to
do
to
make
things
work
and
if
you
water
down
the
text
and
if
we
really
can't
gain
consensus
on,
should
stop
all
ipv4
operations.
I
Lucas
I,
like
yeah,
should
really
like
tone
them
down
or
should
a
you
know,
should
attempt
them
less
aggressively
or
interpret
this
as
a
hint
that
IP
for
it
like.
Definitely,
you
can
interpret
it
as
a
hint
that
off
link
ipv4
is
just
never
gonna
work
unless
the
network's
misconfigured,
so
I
think
you
know
if
we
really.
B
I
It's
very
useful
to
have
positive
when
you're
writing
implementation.
That's
very
useful
to
have
positive
confirmation
of
intent
as
opposed
like.
Oh
this
timed
out
or
there's
an
outage
or
like
something
else
is
not
working
or
I,
have
a
bug
right.
So
I!
Think.
If
you
get
this
positive
signal
from
the
from
Network,
you
can
take
that
under
advisement.
You
don't
have
to
do
what
it
says
nor
you
know.
Nor
will
we
have
consensus
to
say
that,
but
you
can
say:
okay.
Well,
it's
a
signal.
K
Yeah
right
and
also
on
the
security
section,
I
see
a
lot
of
people
talking
about
you
know
if
than
that
and
those
basically,
if
you
don't
have
first
top
security
or
III
type,
filtering
or
or
a
guard
and
those
kind
of
mechanisms,
you're
screwed
at
fifty
to
fifty
ways,
either
we're
making
a
fifty
fifty
first
I
mean
people
seem
to
think
that
you
can
ever
secure
and
fully
open
layer
to
land
with
a
lot
of
hosts
on
it.
There
is
you
can't,
do
it
you're
screwed?
Do
you
need
to
have
that
kind
of
security?
K
A
B
I,
don't
I
actually
wonder
if
I
shouldn't
sit
down
with
Michael
and
Lorenzo
and
write
a
little
paragraph
summarizing
what
we
talked
about
here
and
now
and
suggest
at
try
that
on
the
mailing
list
to
see
if
it
gets
on
census
and
then
reflect
the
updated
document
accordingly,
any
fusil
not
suresh.
That's
how
you
were
raising
your
eyebrows.
C
L
Hello,
so
we
presented
it
in
v6
herbs
in
Montreal
because
we
submitted
the
draft
after
six
months,
so
some
people
might
have
seen
some
of
the
slides
over
idea.
So
the
problem,
what
it's
about?
It's
about,
discovering
not
six
four
prefix,
which
is
Houston
the
network
and
sending
it
to
host
in
erotic
advertisement
in
a
ray
option.
L
So
why
hosts
might
need
to
know
not
six
four
prefix,
because
some
of
them
like
to
do
synthesis
themselves
instead
of
relying
on
dns64
and
validation
stopped
resolvers,
because
every
time
you
talk
about
not
six,
four
in
the
inner
six
whole
Dena's
people
start
crying
and
saying.
No,
it's
break
Dena's
check
whether
they
can
the
resolver
could
not
do
this.
L
L
Standard
known
so
why
we
suggest
in
fifteen
so
sure
can
be
can
standard
is
because
array
is
universal.
You
can
ism
to
get
network
configuration
to
the
host.
You
basically
get
one
packet,
you
get
everything
you
need
quite
fast,
so
there
is
no
moment
in
time
when
your
network
configuration
is
actually
incomplete
and
also
network
is
actually
the
only
proper
source
of
that
information,
because
if
I
run
the
network
I
know
if
I
run
not
successful
and
if
I
do
I
know
which
prefix
is
used
and
where
the
prefixes
are
out
and
so
on.
L
So
we
don't
need
to
run
any
additional
services,
because
one
of
the
other
ways
to
discover
prefix
their
PCP
and
I
do
not
think
many
people
on
protocol.
Also,
it's
secure
because
I
just
discussed
you're
supposed
to
have
a
guard
otherwise
you're
in
trouble
anyway,
and
getting
wrong
prefix
would
be
list
of
your
problem
and
also
we
get
out
of
this
strange
situation
when
you
trust
random,
genus
response
to
get
a
prefix
just
reduce
to
do
dns
circulator,
because
a
fusion
70/50
which
he
relies
on
host
resolving
ipv4,
only
name
getting
v6
address.
L
They
can
quad
a
record
and
getting
prefix
from
the
tracker.
That
means
that
host
needs
to
trust
dns
and
if
you
want
to
do
DNA
check
I
assume
you
do
not
trust
DNS.
So
it's
a
kind
of
paradox
here.
So
Dinah's
people
as
far
as
I
know,
really
do
not
like
way
of
discovering
prefix
var,
but
it's
all
big
names.
So
simple.
We
have
a
simple
format.
L
The
key
thing
here
only
support
suggestion
support
only
96
prefix
and
the
motivation
for
this
is
to
save
size,
because
if
you
try
to
get
a
variable
prefix
length,
it
means
that
option
will
be
now
not
16,
but
24
bytes
and,
unfortunately,
arrays
couldn't
be
fragmented.
So
it
does
make
sense
to
save
size
of
the
array
option
so
type
plants
lifetime
lifetime
needed,
because
you
might
want
to
change
the
prefix
from
one
to
another.
So
you
should
be
able
to
deprecated
one
prefix
and
get
another
prefix
and
ninety-six
bit
for
a
prefix.
L
So
we
have
had
some
discussion
on
mailing
lists
and
most
of
the
discussion
comes
down
to
what
to
do
with
multiple
prefixes.
So
how
could
you
end
up
with
multiple
prefixes?
First
of
all,
this
option:
one
option
specifies
one
prefix
only,
but
you
can
get
more
than
one
option.
Any
single
already
one
of
the
obvious
use
cases
remembering
I
want
to
duplicate
one
prefix
and
get
another,
so
you
send
Ian.
L
Karev
is
one
prefix
with
zero
lifetime
and
nonzero
lifetime
for
second
Prix,
but
in
general
it
means
that
host
might
receive
pre-fill
array
with
multiple
prefixes.
So
there
are
three
actual
scenarios
when
you
host
my
end
up
with
different
prefixes,
first
host
Manitoulin
prefixes
from
their
different
mechanism,
7050
pcp,
maybe
even
and
are
a
second
scenario,
is
the
rosanna
array
is
multiple
prefixes
and
third
scenario
is
multiple
arrays
coming
from
one
or
multiple
interfaces,
so
it's
basically
multihomed
host.
So
first
two
scenarios
is
actually
no
difference
from
what
we
have
now.
L
So
what
we
suggestion
is,
if
different
mechanisms
I
use
to
learn
the
prefix.
There
is
a
recommended
order,
because
seventy
two
to
five,
which
is
PCP,
it's
a
very
sophisticated
way
to
provide
prefixes
to
hosts,
and
it's
allow
you
to
do
a
lot
of
complex
stuff.
There,
of
course
support
this
yeah.
Well,
it
could
prefer
that
mechanism,
and
then
array
option
is
definitely
should
be
preferred
over
dns-based
discovery,
because
it's
actually
a
motion,
fewer
and
it's
more
reliable
if
multiple
prefixes
with
nonzero
lifetime,
for
some
reason,
appears
in
the
single
array
well
for
consistency.
L
We
currently
saying
it
should
do
the
same
thing
as
70/50
says.
The
tricks
here
are
70
50
says
you
must
use
all
of
them
and
as
far
as
I
know,
no
implementation
actually
does
that
they
all
just
pick
up
one
and
do
this,
but
it's
just
for
consistency,
because
otherwise
we'll
get
in
to
complex
behavior.
But
again
it's
should
sure
implementations
might
not
follow
that
sort
scenario:
multihoming.
Okay,
it's
mostly
q1
because
currently
hosts
are
not
doing
dealing
very
well
with
different
configuration
information
coming
from
different
sources
right,
so
obviously
prief
not
successful.
L
L
You
might
experience
unexpected
results
right.
So
really
hosts
should
be
PvdA
aware
to
deal
with
multiple
prefixes,
as
well
with
multiple
DNS
information
we
learns
and
I
had
discussion
about.
Should
it
be
called
limitation,
so
issues
discussed
on
the
list.
I
call
it
limitations,
because
it's
basically
things
which
you
cannot
do
visit
option
does
not
mean
you're
actually
should
be
doing
it
with
that
option.
But
so
first
it's
one
prefix
in
one
option
for
all
destinations.
L
L
No
another
concern
raised
on
the
mailing
list
was
you
there
is
no
way
to
signal
to
hosts
that
some
prefixes
should
not
be
translated
at
all.
But
again
we
talking
the
main
use
case
for
this
a
is
ipv6
only
network.
It's
not
situation
when
your
network
is
actually
dual
stack,
but
you
have
not
six
for
somewhere
else
and
you
want
some
traffic
to
not
to
be
translated
also
because
on
v6
only
network,
even
if
you
do
not
translate
an
address
and
have
an
area
craft,
what
can
you
do
visit
literally
nothing.
L
So
if
application
really
for
some
reason,
needs
to
have
an
a
record,
it
could
easily
leave
yours
in
the
making
because
it
does
no
not
sixth
form,
also
by
the
way
private
address
space
must
not
translated
using
well-known
prefix.
So
it's
kind
of
way,
if
you
want
to
have
your
corporate
network
or
something
this
private
address
space
not
to
be
translated,
just
used,
well-known
prefix,
the
cost
translator,
at
least
as
per
RFC,
must
not
translate
using
well-known
and
again
it's
the
same
problem
which
you
would
have
with
seventy
two
to
five
four
seven
to
fifteen.
L
So
the
question
is
actually
do
we
really
need
it
and
if
you,
if
we
need
it
for
some
special
use
case,
maybe
it's
actually
worth
specifying
another
option
for
variable
prefix
length
which
will
be
bigger,
but
you
don't
need,
don't
have
to
use
it
if
you
just
need
/,
96
and
I
think
it's
been
productive
discussion
on
the
list.
There
are
few
and
clarifying
common
clarifying
things.
We
still
need
to
do
because
we
got
a
feedback
that
some
sentence.
That
might
be
not
so
clear.
L
E
Hi
there
Fred
Baker
Iasi,
or
something
like
that
number
one
I
support
adoption.
I
think
this
is
much
better
than
what
what
we're
doing
right
now.
Number
two
I've
got
an
issue,
and
that
is
that
you
don't
want
to
translate
private
addresses
into
an
ipv6,
prefix
yeah.
So
third
sub-bullet
there
that
creates
a
problem.
So
last
week,
I
spent
some
time
in
a
country
that
is
trying
to
deplane
in
red.
They
want
to
connect
all
of
their
primary
and
secondary
schools,
and
they
want
to
run
an
ipv6
only
network.
E
They
believe
that
they're
going
to
have
some
ipv4
requirements
and
they
need
to
be
able
then
to
connect
to
some
upstream
network,
and
so
what
they
would
like
to
do
is
run
4,
6,
4,
X
lab,
which
would
take
the
ipv4
traffic,
put
it
into
a
v6
traffic,
sent
it
across
the
network
and
then
run
that
through
an
ad
sex
for
translator.
So
it
now
comes
up
when
they
won't
own
IP
earth,
with
a
for
the
global
ipv4
address
and
goes
to
whatever,
and
it
does
whatever.
E
L
No,
no,
no!
It's
well
known
prefix!
It's
only
if
you're
using
six
four
sixty
four
five
nine
be
the
Arrecife
translator
size
must
not.
This
is
what
we're
referring
to
it's,
not
us.
It's
a
translation.
Rfc
clearly
states
that
private
address
space
must
not
be
translated
using
well-known
prefix,
which
64
ff9
be.
If
you
use
in
any
other
prefix,
you
are
perfectly
fine
and
again
it's
not
our
draft
limitation.
It
must
note
from
translation,
RFC.
L
L
N
Dancing
burek
of
okay
Fred
anyway,
in
this
project
we
know
the
project.
I,
don't
think,
that's
a
problem.
We
can
talk
like
Tyrone
on
that.
Okay,
I
support
the
document,
I
I
provided
some
some
comments
in
the
list
and
I
realize
it,
which
your
presentation
that
I
miss
it
something
but
more
or
less
I
think
we
are.
We
are
aligned,
the
the
preference
order
that
you
are
suggesting
for
the
for
the
selection
of
the
of
the
prefix
I
think
you
said.
First,
the
PCP
PCP,
because
yeah
yeah.
L
N
N
My
in
our
document
in
b6
ops
about
the
Seas
which
ipv4
as
a
service
support,
we
had
the
same
order:
I
included
in
one
of
the
versions
the
support
for
this
document,
but
because
we
were
in
the
last
call,
I
need
to
to
retire
that,
but
I
have
included
also
one
more
document.
Maybe
you
want
to
check
that
in
the
actual
version
10
of
my
document
is
4
6
4,
6,
4,
X,
lat,
fine,
it
5.
So
I
am
doing
this
order.
Rfc
7
2,
2
5,
then
8,
1,
1.
L
B
M
L
L
I
M
B
L
C
L
C
L
C
And
the
other
thing
is
like
it's
not
clear.
Is
the
lifetime
right
like
so
the
other
make
it
like?
72
25
doesn't
have
a
lifetime
in
it
at
all
right
and
the
lifetime
is
like
you
know.
How
is
it
age
like
you
know
how
it
gets
like
thrown
out
and
everything
is
not
specified,
so
I'm
not
really
sure
what
the
lifetime
adds
and
that
could
give
you
the
extra
bytes.
If
you
want
lifetime.
L
Adds
an
ability
to
duplicate
the
prefix
and
change
from
one
prefix
to
another,
because
if
I
need
to
change
the
prefix
I
can
currently
the
same
as
we
do
in
this
Pio
I'm
saying
in
one
RA
to
P
two
options:
one
hold
prefix
with
zero
lifetime,
one
new
prefix
with
nonzero
lifetime
and
hosts
I
instructed
to
stop
using
old,
pre-fills
and
start
using
new
one,
because
otherwise
you
have
no
way
whatsoever
right
to
change
the
prefix
for
the
host
host.
You
could
not
signal
back
to
us.
L
C
B
I
Are
very
quickly
yeah,
I
I.
Have
no
objection
to
I,
have
no
objection
to
adding
this
stuff
that
I'm
not
going
to
implement
anyway
I'm
fine
with
that
I
really
am
I
I
do
want
the
working
group
I'll
leave
that
up
to
the
working
group
I
mean,
but
my
implementation
is
gonna,
be
what
I
want
to
do,
but
the
I
leave
that
up
to
the
working
group
in
the
sense
that
we
should
think
about
like
this
thing
is
gonna,
be
with
us
for
a
long
time.
I
I
I
I
B
So,
but
what
do
you
want
to
do?
I
was
about
to
say
to
Jane
that
can
you
go
and
talk
to
Mark
Andrews
really
understand
his
point
and
come
back
to
the
mailing
or
the
working
group
on
the
mailing
list,
and
and
summarize
that
at
least
I
would
like
us
to
understand
his
point
better
and
and
then
we
can
do
that
option
call
just
or
not
on
the
mailing
list.
I
think
there
is
support
for
these
drafts.
That
I
think
that's
going
to
be
just
a
a
quick
thing:
yeah
right:
okay,
Tom
Herbert!
O
O
B
K
O
Thank
you.
Okay,
so
I'm
gonna
talk
about
ipv6
options,
destination
options,
help
I
hop
options
and
some
of
the
efforts
to
make
them
practical
for
use
on
the
Internet.
There
were
two
drafts
that
are
part
of
this.
One
is
ICP
ICMP
limits,
that's
actually
a
working
group
draft,
it's
incorrectly
labeled.
That
draft
has
been
around
I
believe
since
May
and
got
some
initial
comments
and
I
think
would
like
a
response
or
feedback
on
whether
and
that
should
be
working
group
last
call.
The
other
draft
is
newer,
update
ops.
O
So
this
is
basically
clarifications
of
options
from
RCA
8200
and
my
question
there
would
be.
Should
this
be
a
working
group
item
next
slide,
please
so
a
general
problem,
as
probably
everyone
he
knows,
ipv6
options
are
not
considered
viable
and
there's
been
a
lot
of
discussion
on
this.
A
lot
of
workarounds
clarifications
have
been
happening,
so
there
was
obviously
the
clarification
in
RFC
8200
about
hop-by-hop
options.
Some
of
the
other
issues
people
have
quoted,
so
there's
no
useful
options
to
find
the
processing
overheads.
That
glv
is
are
very
expensive.
O
Of
course,
there's
extension
header
drops
that
are
described
in
RFC.
Seventy.
Seventy
eight
seventy
two
and,
in
addition,
the
options
really
are
an
unlimited
to
some
extent,
so
there
can
be
a
lot
of
these
in
a
single
packet
and
that
creates
a
dose
vector.
That's
pretty
obvious
and
RC
26:24
60
require
clarification
on
the
hop-by-hop
options.
O
Next
slide,
please.
So
in
terms
of
useful
options,
there's
at
least
four
that
I
know
of
that
are
being
proposed.
So
there's
a
truncate
option,
MTU
option
and
into
I
am,
but
all
of
these
I
believe
are
hop-by-hop
options
or
destination
options
in
the
case
of
truncate
and
firewall
and
service
tickets,
as
a
proposal
to
use
hop-by-hop
options
next
slide.
O
So
RFC
8200
created
this
exclusion
for
hop-by-hop
options
that
allows
nodes
to
basically
ignore
hop-by-hop
options.
This
was
a
good
step
forward
in
the
sense
that
it
relaxed
a
requirement
that
every
node
has
to
process
these,
which
would
have
me
meant
every
router
has
to
have
hop-by-hop
options,
basically
in
the
fast
path,
so
that
was
fairly
little
austere
as
an
option,
and
this
is
relaxed
nor
see
8200.
O
However,
this
did
raise
a
question
for
me
thinking
about
specifically
the
truncate
option
in
the
truncate
option
that
requires
that
the
packet
is
dropped
if
the
packet
has
been
truncated,
which
means
somebody
along
the
path
has
to
actually
look
at
that
option
and
drop
it.
So
when
I
made
the
recommendation
that
that
should
be
hop-by-hop
option,
it
occurred
to
me
that
if
everybody
ignores
hop-by-hop
options,
including
the
final
node,
then
the
packet
could
actually
be
delivered
to
the
destination.
That's
corrupted.
O
So
if
you
look
at
this
specific
text,
it's
now
expected
the
nodes
of
long,
a
hapa
help
or
long
a
package
delivery
path
only
examine
and
process.
It
I
think.
The
question
that
I'd
like
to
raise
is:
does
that
mean
that
the
destination
is
allowed
to
ignore
the
hop-by-hop
option,
or
is
that
not
in
the
package
delivery
path
and
has
to
actually
process
it?
So
that's
probably
a
question
that
I
would
raise
do
the
working
group
are
on
the
list
next
slide,
please.
O
So
the
update
options
clarified
adding
removing
and
changing
options.
Basically,
this
says
that
the
only
thing
that
can
change
in
an
option
is
the
data.
If
the
third
bit
in
the
option
type
is
marked,
the
option
is
changeable,
so
option
types
cannot
be
chained,
changed
option,
lengths
cannot
be
changed,
options
can't
be
deleted,
can't
be
added,
and
that
includes
extension.
Headers
hapa
help
options.
Destination
options
cannot
be
at
it
or
delete
it.
O
So
I
believe
this
is
just
a
clarification
of
RFC
8200,
and
that
was
the
spirit
of
already
RC
8200
next
slide,
please
so
another
clarification
and
update
option.
This
is
changeable
destination
options,
so
in
fact,
the
bit
in
the
destination
options
type
can
be
marked
as
changeable
and
RFC.
8200
was
not
exactly
clear
on
that,
so
the
text
and
the
update
options
is
in
two
modes.
O
So
if
the
destination
option
this
precedes
the
routing
header,
then
any
visiting
node
may
change
the
option
data
so
this
effectively
our
nodes
in
route
that
are
being
visited,
so
that
is
along
the
lines
of
what
changeable
means.
Now
the
question
is:
how
does
a
node
know
that
the
destination
options
are
before
routing
header
so
that
it
can
ignore
it
and
I
think
the
heuristic
there
is
that
you
node
can
actually
look
at
the
next
header
of
the
of
the
destination
options.
O
If
the
routing
header
is
present,
the
next
Center
should
be
according
to
the
canonical
ordering,
the
routing
header.
The
other
option
is:
if
the
destination
options
are
after
or
without
the
routing
header,
then
the
option
cannot
change
in
route.
However,
the
bit
can
still
be
set,
which
means
the
authentication
for
our
purposes
of
authentication.
Data
has
to
be
zeroed,
so
it's
unchangeable,
but
still
has
to
be
consistent
with
the
authentication
header,
treating
it
as
changeable
next
slide.
Please.
O
Another
update
to
the
update
options
is
destination,
option,
processing
requirements
so
again
this
splits
it
into
options
that
precede
the
routing
header
and
those
after
the
routing
header.
In
the
case
that
options
precede
the
route
header,
the
proposal
is
that
they
may
be
examined
or
processed
by
intermediate
destinations,
and
the
rationale
for
this
is
that,
when
routing
headers
in
use,
the
likely
nodes
in
the
better
intermediate
are
probably
more
like
routing,
routers
or
middleboxes
than
n
host.
So
in
the
same
rationale
that
hop-by-hop
options
can
be
ignored
by
those
sort
of
devices.
O
This
is
proposing
that
destination
options
that
precede
the
routing
header
can
also
be
ignored
in
the
same
way
destination
options
that
are,
after
a
routing
header
or
there's
no
routing
header,
they
have
to
be
processed
regardless.
There's,
no,
no
exclusion
as
to
that
as
far
as
I
know
next
slide
please.
So
this
is
the
extension
headers
limits,
the
other
draft
or
no
I'm.
Sorry,
this
is
our
C
64
34
bits.
This
was
text
that
we
added
in
order
to
provide
limits,
and
this
primarily
solves
the
problem
that
options
can
be
unlimited.
O
So
it's
very
easy
to
create
a
large
packet
with
a
whole
bunch
of
options
that
were
basically
known
to
be
unknown,
however,
marked
not
to
be
skipped,
so
this
is
an
easier
to
analysis,
attack,
I,
think
I
had
packed
packets
with
like
seven
or
eight
hundred
nan
padding
options,
and
there
was
a
big
performance
hit
when
I
know
tried
to
process
all
of
those
they
have
to
be
sequentially
processed
and
per
the
current
specification.
They
have
to
be
processed.
O
So
the
idea
was
to
limit
the
padding
options,
disallow
unknown
options
optionally,
but
also
have
limits
on
the
number
of
non
padding
options
and
limit
the
length
of
both
hop-by-hop
sha
or
destination
options.
Extension
header,
so
this
text
was
added
to
our
c64
34
4
bits
and
actually
it
has
been
implemented
in
linux
and
it's
been
running
for
a
while,
and
the
default
limits
for
a
number
of
options
is
actually
set
to
8
next
slide,
please.
O
O
This
one
is
not
specific
to
the
IP
header.
It's
actually
a
more
generic
thing
that
we
added.
So
the
concept
here
is
that
the
header
chain,
whether
it
be
IP,
encapsulation,
headers
what-have-you,
is
considered
too
long.
The
rationale
here
is
that
there
are
intermediate
devices
that
have
a
parsing
buffer
and,
if
that
perfing
parsing
buffer
is
exceeded,
they
may
drop
the
packet,
so
they
could
actually
send
this
ICMP
error.
O
In
that
case,
as
I
said,
the
behavior
of
receiving
an
ICMP
err
on
the
host,
they
can
either
adjust
what
they're
sending
or
they
can
log
it.
However,
in
any
case,
there
is
some
error,
that's
being
returned
and
now
with
the
ICMP
errors
for
these
next
slide.
Please
I
one
point
about
the
implementation,
so
we
know
that
there's
a
lot
of
legacy
nodes
that
don't
handle
options
very
well.
O
So
are
we
expect
our
FCAT
to
hundreds
exclusion
to
help
the
devices
skip
options
instead
of
just
dropping
them
for
hot,
buy
help
options,
but
that
that
is
a
difficult
problem
that
we
need
to
solve
over
time.
We
do
expect
the
limits
that
are
being
allowed
in
RFC
6040
through
our
64
34
bits
should
aid
but
hardware
and
software
implementation.
O
As
I
said,
the
skipping
hop-by-hop
that
had
it
up
by
hop
options
should
be
straightforward
for
a
device
to
implement
and
the
one
trend.
That
may
be
very
helpful.
Here
is
the
emergence
of
programmable
devices.
These
should
make
it
a
lot
more
Mina
Bowl
to
implement
support
for
options
and
intermediate
devices.
One
comment
about
that
is
both
p4
and
BPF,
which
are
the
kind
of
languages
of
the
bytecode
of
these
programming
devices.
Typically
don't
allow
loops,
however,
through
enrolling,
it
seems
reasonable
that
they
could
allow
about
eight
options,
so
eight
options
in
a
packet.
O
H
Bonica
juniper
networks,
I
think
this
draft
may
be
premature
and
I'll
I'll.
Take
an
example
to
show
how
RFC
8200,
maybe
a
little
bit
loose
about
its
specification
of
processing
destination,
option
rules.
You
bring
up
one
rule,
whether
it's
okay
to
ignore
a
destination
option
that
precedes
a
routing
extension
header.
Well,
maybe
the
rule
is
it
stated.
Nate
8200
is
correct.
Maybe
the
rule
is,
you
stated
is
correct.
H
We
really
don't
know
because
nobody's
ever
specified
a
destination
option
that
comes
before
a
routing
extension
header,
lacking
the
operational
experience
lacking
the
protocol
design
experience
with
this
destination
option.
Do
we
want
to
make
the
rule
now
or
do
we
want
to
lay
wait
until
we
actually
want
to
use
this
option
and
then
think
about
what
the
rule
might
be
so.
O
The
this
room
was
actually
motivated
by
segment
routing,
which
has
tlvs
and
one
of
the
rationales
they
had
for
tlvs
and
segment
routing,
as
opposed
to
using
destination
options
before
the
routing
header
was
that
destination
options
could
not
be
ignored
and
they
wanted
the
ability
to
ignore
them.
So
that
was
actually
the
rationale
for
this
was
to
satisfy
one
of
the
requirements
that
at
least
the
segment
routing
tlvs
had-
and
you
know,
I
was
one
of
the
believers
that
destination
options
should
be
sufficient
for
what
they
were
doing
with
the
segment
routing
TLV.
H
O
Well,
and
so
again,
the
the
principle
here
was
that
the
devices
that
are
in
in
a
routing
header,
the
our
intermediate
devices,
which
typically
wouldn't
process
us
what
what
I'm
afraid
would
happen
is
we
will
define
destination
options
before
the
routing
header
and
we're
going
to
get
into
the
same
state.
We
had
in
hop-by-hop
options
where
nodes
are
just
ignoring
them
without
any
any
specification,
though,.
L
O
H
L
J
A
Okay,
so
we're
gonna
wrap
this
up
we're
over
time.
So
I
think
this
needs
more
discussion
and
lists,
but
I
also
know
that
there
are
two
drafts
here.
One
is
just
defining
ICMP
error
codes,
which
I
think
it's
a
much
lower
bar
than
the
other
draft,
which
is
changing
behaviors,
so
they
need
to
be
considered
separately.
Okay,
thank
you.
Tom
thank.
B
B
You
know
the
solution,
space
for
path,
MTU
discovery,
so
I'll
quickly,
walk
through
that
since
I
was
the
reason
didn't
manage
the
time
very
well
for
all
the
other
speakers,
so
you
know
a
bit
short
on
time,
I'll
just
sold
out
by
speaking
very
quickly,
and
so
why
are
we
doing
this
RC
1981-82?
Oh
one
has
some
issues
with
robustness,
especially
around
signaling.
Back
to
the
sender.
It's
truffled
in
Reuters,
that's
RFC,
four,
four,
four:
three!
B
It's
filtering
firewalls
it's
ignored
by
host
doesn't
work
well
with
any
cost
low
bouncing
with
v4
II,
wasn't
even
enough
net
payload
in
the
ICMP
error
message
to
correlate
which
sending
packets
we
were
talking
about.
It
also
requires
multiple
round
trips
to
detect
the
full
path
MTU
and
it
detects
empty
upper
destination,
not
flow.
B
So
that's
why
we?
You
know:
can
we
do
anything
else?
There's
been
a
lot
of
work
on
path
MTU.
Over
the
year
we
haven't
made
much
more
progress
than
where
we
are
now
with
ICMP
base,
P
and
Q
in
the
routing
area.
There
is
work
going
on
now,
especially
around
segment
routing,
where
you
advertise
the
MTU
in
in
routing
protocol.
So
that's
one
option:
multicast
they're
doing
their
own
thing
for,
for
beer
pamphlet,
those
in
detail.
B
What
we
want
to
have
is,
of
course,
robust
that
should
be
possible.
Deployable
is
probably
the
hardest
one.
It
would
be
nice
if
you
could
detect
the
path
MTU
in
a
single
RTT,
not
making
an
easy
target
for
filtering,
which
means
that
the
sender
of
the
signal
back
should
be
the
destination
host
and
it
should
probably
be
hidden
in
the
transporter
or
application
stream,
not
as
a
separate
ICMP
message.
B
It
would
be
nice
if
it
was
per
flow
because
packets
with
different
you
know,
five
tuples
are
routed
differently
and
there's
a
separate
topic
on
supporting
/
neighbor
path
into
you,
which
is
you
know.
You
have
multiple
hosts
on
the
same
link
that
would
then
use
heterogeneous
empty
on
that
link
to
communicate
when
you're
talking
about
the
solutions.
B
B
There
are
some
downsides
of
that.
It's
it's
not
super
efficient.
They
can't
distinguish
between
you
know:
congestion
drop
or
an
MTU
failure,
for
example
this
it's
not
perfect,
but
that
it's
pretty
much
more
transport
has
to
do
today
anyway,
because
he,
you
know
what
we
do
at
a
network
layer
is
robust
and
it
probably
isn't
going
to
be
right
for
at
least
for
knocking.
You
can.
B
B
There
are
some
issues
with
this.
You
know.
If
you
want
to
do
special
probe
packets,
you
can
do
that
or
you
can
embed
it
with
the
normal
data
packets.
Then
you
have
to
record
your
regional
payload
length.
You
might
eat
tissues
with
firewalls
and
things
that
Shakti
speech
exomes
for
examples
you
have
to.
You
have
to
do
a
little
bit
of
magic
and
they
would
carry
some
metadata
with
the
packet
when
you
do
that.
B
This
is
really
a
clean
slate.
You
know
throw
all
the
balls
up
in
the
air
again
see
if
we
can
come
up
with
something
better
at
the
internet
layer
I
mean
we
clearly
can
do
this
in
the
transport
layer
on
the
air
or
in
the
applications
with
probing,
but
it
might
be
helpful
if
we
could
give
some
better
hints
and
clues
to
to
the
transport
layer.
So,
yes,
questions,
Mike,.
K
K
No,
no
ma'am,
it
is
like
first
and
first
of
all,
I
think
you
missed
a
few
reasons
why
this
doesn't
work.
I
keep
iterating
it
people
seem
to
keep
forgetting
it
is
it's
like
you
know,
layer,
2
devices
in
the
middle.
It's
not
configured
for
lower
empties,
you
get
silent
drop,
but
there
are
lots
of
reasons
why
this
doesn't
work.
So
we're
going
to
need
everybody
to
do
a
little
bit
of
everything,
so
the
packet
we
need
to
tell
transport
and
that
they
need
to
do
packet
layer
about
them
to
discover
for
robustness.
K
They
can't
just
say
you
know
the
network
will
fix
it
and
we
don't
have
to
do
anything
so
they
were
going
to
do
that.
We're
some
of
the
other
ideas
are
I.
Think
they're
good,
like
the
truncation
on
the
way
might
I,
don't
know
what
do
the
hardware
people
say
about
the
truncation
part
like
people
making
infuse
they
happy
with
that
or
it's.
P
N
P
K
Slow
path?
Okay,
so
it's
punted!
It
said
you're
not
always
going
to
do
that
right,
because
if
there's
a
lot
of
packets,
you're
gonna
be
able
to
handle
them.
So
if
that's
gonna
work,
it's
an
I
would
say
it
needs
to
be
done
in
a
high,
not
slow
path,
but
okay.
So
we
had
two
more
sessions
right,
one
on
probation,
one
where.
K
A
A
Q
Q
And
adapting
to
varying
path,
MTU
needs
to
be
done
over
the
connection
lifetime.
We
can't
just
assume
that
we
finally
talked
at
the
beginning
and
that's
the
way
it
stays
the
Swart
flaws.
It's
probably
true
for
long
floors,
it's
certainly
not
true,
and
that
might
mean
raising
the
m2u
from
time
to
time.
We
can
do
all
this
stuff
at
the
transport,
of
course,
because
I've
got
a
draft
in
TS
vwg,
which
we'll
talk
about
this
week.
Q
That
does
it
at
the
transport,
but
it
can
require
an
awful
lot
of
probes
if
you
want
to
go
for
big
half
and
tears
and
we'd
like
to
do
it
in
a
single
empty
like
do
it
in
a
single
round
trip
if
we
can,
or
at
least
have
options
for
doing
it
really
quickly,
and
it
needs
to
work
with
device,
is
that
read
transport
headers
and
because
these
guys
will
need
real
pockets
because
the
route
packet
takes
through
the
network
will
depend
upon
the
transport
headers
such
the
UDP
port
information.
So
that's
the
goals.
A
Okay,
so
so
I
think
you
understand
the
problem
of
you
know.
You
know,
sender
knows
the
first,
those
little
a.m.
to
you
of
its
outgoing
link,
but
it
doesn't
know
anything
about
the
rest.
So
next,
okay,
so
so
this
is,
you
know
the
format
of
the
hop
by
op
option.
It
me
it's
very
simple:
it
just
has
the
you
know
the
option
type
and
all
the
bits,
and-
and
we
know
that
I
8200
now
says
you-
you
know
it's
okay
to
skip
these
things,
but
I
was
thinking.
This
actually
might
be
a
useful
hop
hop.
A
If,
if
at
every
hop,
it
sees
that
the
MTU
has
changed
from
what
was
originally
written,
that
you
write
the
smaller
value
in
so
if
it's,
the
outgoing,
is
less
than
you've.
You
update
the
thing
and
then
the
destination
receives
this
and
it
can
send
a
package
of
big
message
back
to
the
source.
So
it
will
know
yeah
we're
trying
to
do
this
quickly
because
we're
out
of
time,
but.
Q
It
might
be
wrong,
and
we
know
this-
that's
okay.
We
just
want
a
hint
we're
going
to
drive
this
at
the
packetization
layer
to
do
the
real
checks
we
just
wanted
good
hint
as
to
what
size
to
probe
for-
and
we
don't
rely
on
this
option-
read
the
draft
about
that.
But
really,
if
reuters
don't
update
this
on
the
way,
then
okay,
then
we
just
don't
get
the
information.
We
have
to
try
probing
in
the
usual
way
and.
Q
A
Yeah
and
so
there's
a
you
know,
as
only
talked
about
this,
you
know
other
work,
reporting,
high
drop
rates
and
this
stuff
there's
other
graphs.
It's
also
going
to
be
discussed
in
the
transport
area
or
TS
vwg
I
think
tomorrow,
tomorrow,
ok,
sir
yeah
and
so
sort
of
the
adoption
question.
But
what
do
you
think
about
this.
K
Michael
Abrams
is
a
I
think
last
time
when
I
looked
at
this,
it
didn't
specify
which
MTU
so
if
I
have
an
interface,
MTU,
ipv4,
MTU
and
I'm
TV
6and
to
you
this
is
these
are
three
different
values.
Is
it
deep?
Whatever
packet
type
came
in
and
to
you
that
you
want
back
you're
forwarding
this
packet,
you
make
the
forwarding
decision,
you
take
the
MT
you're
gonna
use
for
forwarding.
Okay,
so
the
max
encapsulated
packet
I
can
I
can
do
it
at
the
grace.
Okay
and
then
I
made
a
point,
I
think
about
ingress.
K
Q
K
K
A
K
Q
C
What
does
what
happens
to
the
socket
itself,
because,
like
one
of
the
proposals,
are
sending
it
along
with
the
syn
packet?
So
would
that
reset
the
connection
after
like
what
happens
to
the
circuit?
It
should
signal
an
error
because
the
hard
error,
the
packet
too
big,
it's
not
on
the
software,
a
category
right.
Q
Does
packet
too
big
imply
that
the
destination
also
drops
it
when
it
issued
by
the
destination?
We
don't
usually
have
ICMP
like
this
from
the
destination
right
so
and
I
think
it'll
reset
the
connection.
That's
what
I
do
we
were?
We
were
hoping
it
wouldn't
be
dropped.
We
were
hoping
that
somehow,
the
packet
too
big
from
the
destination
wasn't
treated
in
that
way.
Okay,
I
need
to
talk
about
that.
We'll
talk
about
that
yeah
thanks.
L
She
wants
a
packet
rate,
compare
and
to
what
I
did
a
couple
years
ago
and
I
have
a
question:
I
did
not
find
it
in
the
draft.
I
was
sure,
as
the
trousers
do
not
do
load
balancing
be
differently
for
paycut,
for
packets,
with
extension,
header
and
without
them.
So
you
might
actually
go
through
completely
different
paths:
I'm,
sorry,
mass
consumption.
Oh
it's.
L
Q
K
Okay,
I
know
I'm
Charlie,
Peter,
fun.
Deke
is
saying
for
this
specific
case
of
DNS,
where
a
resolver
cents,
Aquarion
of
authoritative,
something
the
auth
sensor,
responds
the
resolver
might
issue
the
PTB
and
that
through
out
the
packet
away.
However,
if
they
result,
it
is
the
resolver
that
wants
to
know
this
number
because
it
can
communicate
it
as
an
e
dns
buff
size.
So
for
both
this
proposal
and
the
next
one,
it
would
be
wonderful
if
we
could
expose
this
number
on
the
receiving
end
to
the
application
later.
So
the
basic
I
think.
H
Okay
exercise
I'm
talking
fast.
We
will
skip
this
slide
because
everybody
already
knows
this:
what
network
services
are
we
trying
to
get
the
truncation
draught
is
trying
to
provide
a
mechanism
so
that
when
a
source
node
sends
a
packet
that
is
bigger
than
the
PMT
you?
He
gets
immediate
feedback.
The
feedback
mechanism
has
to
be
activated
on
a
per
session
basis
by
the
upper
layer
protocol
by
default.
The
feedback
mechanism
is
turned
off,
so
the
upper
layer
protocol
turns
it
on
for
a
session
that
he
wants.
H
Feedback
on
the
feedback
must
detect
mechanism
must
detect
PMT,
u
decreases,
but
it's
not
required
to
detect
PMT,
u
increases,
and
it
must
be
more
reliable
than
PMT
UD
is
today,
but
it's
not
required
to
be
a
hundred
percent
reliable
and
the
reason
for
that
is
that's
a
goal
that
we
just
can't
achieve.
So
what's
the
approach
we
want
to
make
PMT
you
deem
more
reliable
today
when
a
source
node
sends
a
packet
bigger
than
the
PMT
p.m.
to
you.
H
It
gets
one
ICMP
message
and
that
ICMP
message
is
sent
by
the
intermediate
nose
that
did
the
truncating
in
the
proposed
approach.
The
source
node
will
get
two
ICMP
messages,
one
from
the
intermediate
node
that
did
the
truncating
and
another
by
from
the
destination
node.
Now
to
make
that
happen,
obviously
the
packet
needs
to
get
to
the
destination
node.
Somehow,
if
the
network
fails
to
deliver
the
ICMP
message
from
the
intermediate
node,
there's
some
chance
that
it
might
deliver
the
ICMP
message
from
the
destination.
H
H
So
let's
talk
about
the
current
version
of
draft
letty,
the
version
that
you
read.
If
you
look
at
what's
posted
the
source,
node
pack
marks
a
packet
with
a
truncation
eligible
option.
If
an
intermediate
node
can't
for
the
packet
because
of
an
MTU
issue,
it
sends
an
ICMP
PTD.
It
overwrites
the
truncation
eligible
with
a
truncated
packet
option.
It
truncates
the
packet
recalculates,
the
upper
layer
checksum,
if
possible,
forwards
the
packet
to
the
destination.
H
If
the
destination
recognizes
the
truncated
packet
option,
it
sends
an
ICMP
message
and
to
the
source
and
it
discards
the
packet.
If
it
doesn't
recognize
the
truncated
packet
option,
it
sends
an
ICMP
parameter
problem
and
discards.
The
packet,
the
reason
for
that
the
truncated,
a
packet
option
begins
with
the
bits
1
0.
If
you
don't
understand,
though,
an
option
that
starts
with
1
0,
that's
the
required
behavior.
Now
this
drew
some
pretty
sharp
criticism.
There
were
two
things
that
people
didn't
like:
one
is
updating
the
checksum
in
flight.
H
The
over
other
is
overriding
the
destination
option
type
in
flight,
so
Sunday
a
bunch
of
the
folks
who
raised
the
objections
we
all
went
into
a
smoke-filled
room.
Yes,
we
were
smoking
tobacco
and
we
came
up
with
two
things
that
we
might
do
to
fix.
The
problem.
One
is
just
don't
update
that
checksum
leave
broken
now.
This
reduces
the
risk
of
the
truncated
packet
being
introduced
to
the
data
stream
at
the
destination.
Now,
how
big
is
that
risk?
H
Well,
it's
hard
to
tell
the
packet
already
carries
an
option
that
will
cause
it
to
be
discarded,
so
it
reduces
the
risk.
You
know,
maybe,
if
there's
some
bug
in
the
destination,
doesn't
you
know
deal
with
options
that
start
with
one
or
correctly?
What's
the
cost?
Well,
it
reduces
the
reliability
of
the
feedback
mechanism.
The
reason
why
is
it
reduces
the
probability
that
the
truncated
packet
will
actually
make
it
to
the
destination.
H
What
we
discovered
is
an
awful
lot
of
stateful
middleboxes
verified
check
sums
and
if
the
checksum
is
wrong,
they
discard
the
packet
silently,
so
it's
just
not
going
to
make
it
to
the
destination.
So
yes,
this
does
answer
the
criticism,
but
it
critically
reduces
the
reliability
of
the
mechanism
and
it
critically
reduces
the
applicability
we'll
talk
about
that
in
the
last
slide.
H
The
next
thing
that
we
could
do
is
collapse.
The
two
options
you
saw
two
options:
truncation
eligible
and
packet
truncated
packet
collapse
them
into
one.
It's
called
trunk
truncated.
The
active
bits
are
1
0.
That
means,
if
this
arrives
at
the
destination
and
the
destination,
doesn't
understand
it.
It's
going
to
drop
the
packet
and
send
the
parameter
problem
message.
The
change
bit
is
0,
which
means
it
can't
be
changed
in
flight
and
the
option
data
is
2.
H
Bytes,
the
two
bytes
are
exactly
the
same
value
that
the
packet
had
at
the
source
in
its
IP
payload
length.
So
how
do
we
process
this
thing?
The
source
node
marks
the
truncation
marks
the
packet
with
the
truncation
destination,
option
the
option
we
just
described.
If
an
intermediate
node
can't
forward
it,
it
sends
an
ICMP
message:
it
truncates
the
packet
and
when
it
truncates
the
packet,
it
changes
the
length
in
the
ipv6
header
and
it
fords
it
to
the
destination.
H
If
the
destination
doesn't
recognize
it,
it
drops
the
packet
and
sends
an
ICMP
parameter
problem
message.
If
it
does
recognize
that
occasion,
option
and
the
length
in
the
option
is
different
from
the
length
of
the
packet.
It
knows
that
the
packet
has
been
truncated,
so
it
sends
an
ICMP,
PDB
and
discards,
the
packet,
and
if
it
recognizes
the
truncation
option
and
the
two
lengths
are
the
same,
that
means
the
packet
hasn't
been
truncated.
In
that
case,
you
can
process
the
packet
now,
let's
talk
about
cost
and
benefits
the
benefit
of
collapsing.
H
The
two,
the
two
packet
types
into
one
of
the
two
option
types
into
one-
is:
it
avoids
overriding
the
option
type
in
flight
this.
This
really
is
a
benefit
when
we
were
changing
option
types.
This
mechanism
didn't
work
with
the
authentication
header
because
it
made
the
authentication
header
integrity
check
break.
Now
it
works
with
the
authentication
header.
H
Additional
cost
incurred
when
the
destination
node
doesn't
recognize
the
option,
so,
let's
say
you're,
sending
to
a
destination
node
that
doesn't
recognize
the
option
and
the
old
formulation.
If
the
packet
wasn't
truncated,
the
truncation
eligible
ended
in
0/0.
No
problem,
there's
no,
you
know
you
accept
the
packet
in
this
case.
H
If
the
destination
doesn't
that
doesn't
understand
the
option,
gonna
get
dropped,
the
packet
get
the
parameter
problem
and
you
waste
an
RTT,
discovering
that
two
minutes
they're
wrong.
What
two
minutes?
Okay,
let's
say:
that's
why
we
can
skip
over
next
steps?
Oh
I,
guess
we're
not
gonna
discuss
the
proposed
changes
here.
P
Igor,
what's
your
name
Igor,
my
name
is
the
eager
eager
am
I
I
was
looking
at
the
checksum
issue.
I'm
not
very
I
mean
we'll
have
a
press
performance
enhancing
practice
do
checksum,
recalculation
all
the
time
for
TCP
packets
and
basically
that
TCP
UDP
is
only
simple,
could
actually
even
carry
computer
checksum
for
and
there
are,
there
is
a
list
of
scene
that
will
break
if
checksum
is
wrong,
but
we
just
want
to
add
to
that.
P
P
A
So
I
was
gonna,
make
an
announcement
so
I
reserved
you
know
few,
where
we're
not
there's
not
working
group
sessions
on
Friday,
but
there
are
side
meeting
working
things,
so
I
reserved
a
room
on
Friday
from
10
to
12,
with
the
goal
of
talking
about
well
discussions
from
six-man
and
TS
v,
WG
about
path,
MTU,
so
I'll
send
mail
I'll
be
in
the
air.
Well,
you
could
take
internet
on
the
plane,
sorry,
but
we'll
the
goal.
The
goal
I
think
it
would
be
useful
to
continue
this
discussion
and
hope.
A
B
Ok,
an
area
bank
asked
me
to
announce
another
side
meeting
and
it
happens
tomorrow
on
the
provisioning
domains.
That's
from
10:00
to
11:00
he'll
send
an
announcement
out
on
the
mailing
list
for
that,
at
least.
If
you're
interested
in
pvd's
have
a
look
at
that.
Could
the
blue
sheets
be
set
forward?
Please
and
I'm
terribly
sorry
to
the
two
authors
for
the
lightning
talk
sessions.
We
have
to
cancel
those.
We
have
we're
out
of
time.