►
From YouTube: IETF100-6MAN-20171114-1330
Description
6MAN meeting session at IETF100
2017/11/14 1330
https://datatracker.ietf.org/meeting/100/proceedings/
B
C
C
C
D
C
A
C
E
Right
so
for
the
document
status
for
this
IDF,
we
have
published
no
documents.
We
did
quite
well
for
the
previous
IDF
with
the
basic
standards
document,
so
don't
feel
too
bad
about
that
one
document:
a
TI
ESG,
that's
the
max
RA
document.
It
has
a
had
a
discuss
which
we
now
think
is
resolved,
so
that
should
progress
quite
quickly.
I
think
we
have
two
and
a
half
active
working
group
documents.
It's
the
our
physics,
node
requirements
which
will
be.
E
We
will
spend
some
time
on
after
this
and
then
segment
routing
and
then
the
RS
Refresh
option
draft,
which
is
expired.
So
the
chairs
will
sit
down
with
the
authors
during
this
week
and
we'll
figure
out
what
to
do
that.
But
if
anyone
has
all
pinions
on
that
document,
you
know
please
jump
up
and
say
something
now.
E
A
F
Eric
coin
there's
also
a
document
in
IP
wave,
that
is
a
survey
of
ipv6
and
vehicle
networking
things,
and
it
includes
a
problem
statement
of
what's
what's
slow
about
ipv6
addressing
as
assignment
and
stuff
like
that,
and
so
there
might
be
something
from
there
coming
to
six-man
for
us
to
think
about.
Maybe
getting
our
SRA
stuff
faster.
They
have
a
document
proposing
like
vehicle,
predict
information
options
and
vehicle
service
options
right,
but
this
is
that
document
is
not
yet
adopted.
Just
sort
of
like
a
potential
documented
interest
resolved.
A
G
Description
so
eighty
for
both
of
the
things,
so
they
are
more
looking
at
the
problems
right
now,
so
they're
not
at
any
kind
of
solution
level.
Yet
right
like
so
even
the
problem
statement
is
not
done
from
the
working
group,
but
they
do
have
like
a
grab-bag
of
problems
and
like
I,
think
Eric
is
just
giving
a
heads
up
that
something
might
come
here
in
the
future
right
now.
G
E
And
I
don't
think
we
have
done.
This
is
a
very
formal
process.
This
is
more
of
a
heads
up
that
there
might
be
things
that
we
want
to
pay
a
little
bit
attention
to,
and
you
know
yes,
Erica
I
think
we
should
that
yeah
at
that
document.
So
we
finished
off.
You
know
getting
the
the
core
standards
off.
So
that's
done
milestone
with
these
four
documents:
8282,
oh
one,
three,
five,
nine,
six
and
four
four
four.
Three.
E
Then
we
have
four
five
document
remaining
at
the
draft
standards
level.
We
can
consider
doing
something
about
on/off
plus,
then
you
know
other
documents
in
the
in
that
we
would
consider
core
to
v6
that
we
also
might
consider
advancing
the
bobbin
I
have
done
no
further
considerations
on
that.
We
can
probably
take
that
to
the
list
or
if
someone
has
strong
opinions
or
what
we
should
do
or
or
not
do
with
these
documents.
At
this
point,
you
know
feel
free
to
jump
up.
E
H
There
shouldn't
be
no
ipv4
in
this
room
for
the
duration
of
the
session.
Please
please
use
not
six
four
SS
ideas.
There
are
tools
there.
One
is
authenticated,
one
is
not,
and
there
is
it
indeed
ipv6
only
which
doesn't
even
have
not
six
four.
So
if
you
really
brave
you
can
try
this
one.
If
by
accident,
if
accidentially
you
can
see,
do
all
stack,
SSID
leaking
from
other
rooms,
please
don't
use
it.
Please
be,
let's
be
honest
and
try
how
things
are
working.
H
If
you
see
something
broken,
please
report
it
to
tickets
meeting
site
here
of
the
torque
and
there
will
be
prizes
ins
and
just
to
motivate
people
to
do
it
and
I
think
if
you
can
go
scroll
down
to
the
last
slide,
so
people
could
yes,
yes,
so
please
use
it.
It's
just
two
hours,
I'm,
pretty
sure
we
can
survive
without
corporate
VPN,
so
you
can
pay
attention
to
what's
going
on
in
the
room.
Thank
you.
H
I
Dudes
can
assi
up,
oh
I,
just
wanted
to
add
from
what
I
saw
in
v6
ops
yesterday,
some
people
are
like.
Oh,
this
doesn't
work.
I,
don't
want
to
care
who
stayed
on
the
ATF
Network.
Not
only
did
none
of
their
stuff
work
because
we're
you're
too
far
from
the
access
point.
They
were
also
scrambling
up
the
air
time
for
people
in
the
other
room.
So
please
double
check
on
your
watch
phone
computer,
dead,
badger
that
they're
all
on
the
right
is
SSID
Thanks,
yeah.
E
E
J
J
J
We
got
either
on
the
list.
Last
time
we
put
out
this
draft
or
we
had
them
in
the
room.
So
you
can
see
the
list
here.
Some
of
them
are
major.
Some
of
them
are
very
minor.
Obviously
we
made
RFC
references
updates
to
the
latest
ones,
pretty
straightforward,
which
leads
me
to
the
next
list
of
open
issues.
We
still
have
left
some
of
these.
We
sent
out
last
week
to
try
to
get
some
early
comments
and
I'll
talk
about
some
of
those
early
comments.
J
We
got.
This
comment
was
list
of
changes.
Currently
they
look
just
like
the
list.
I
showed
you
which
doesn't
really
give
the
rationale
they
a
lot
of
the
changes
we
marked.
We
said:
hey
we
updated
this,
but
we
didn't
explain
why
so
we'll
fix
that
we'll
put
on
why
we
removed
things
from
the
list
or
why
we
made
changes
to
any
of
the
current
stuff
in
there
pretty
straightforward.
J
This
was
a
pretty
big
change
from
the
last
time
we
talked
so
one
of
the
comments
we
got
I
think
from
Eric
and
some
other
people
was
support
for
RFC
4180
one.
So
we
added
it
in
here
now
the
catch
is
when
you
read
that
RFC
it
says
you
have
three
types
of
hosts
and
we
were
it
up
and
said:
okay.
Why
don't
we
say
you
have
to
do
that
RFC,
but
in
this
case
we
said,
should
four
type
see
the
reason
we
did.
J
That
was
because
we
thought
that
was
the
one
that
could
be
the
most
useful.
Obviously
there
are
cases
where
people
will
want
to
do
type:
a
and
B
I'm
sure
there
are
cases
where
there
are
constrained
nodes,
for
example,
or
other
reasons
you
might
want
to
do:
type
A
or
B.
So
we
didn't
make
it
a.
Must
everyone?
Okay,
with
that?
No
one
jumps
up
at
the
mic.
We're
just
gonna
leave
it
like
that.
J
This
so
when
8200
was
going
through,
Tom
wanted
to
put
in
some
text
about
ipv6
extension,
header
processing
and
it
was
suggested
by
Bob,
but
he
put
it
in
the
node
requirements
document.
So
we
got
that
it's
it's
pretty
long.
It's
about
five
paragraphs
worth
of
stuff,
none
of
its
substantial
from
the
sense
there's
no
must
in
here
it's
a
lot
of.
You
may
do
this
and
you
might
want
to
do
that
and
should
think
about
these
things.
It's
pretty
long,
but
especially
for
this
document.
That
is
mostly
reference.
J
J
L
J
J
We
don't
think
there's
a
wide
enough
deployment
or
reason
at
this
moment
if
anyone's
opposed
to
that
come
back
to
us
and
us
I
know
we're
trying
to
close
out
as
many
of
these
options
as
we
can
now,
because
we
think
this
documents
getting
pretty
close
to
last
working
group
also
all
right.
Here's
the
other
one
unknown
upper
layer
protocols,
so
8200
says
there
are
three
types
known
extension,
headers
known
upper
layer
protocols
and
unknown
extension,
headers
there's
also
a
fourth
case
was
pointed
out
on
the
list
for
unknown.
J
If
you
don't
know
who
your
upper
layer
protocol
is,
they
can't
be
distinguished
from
unknown
extension
headers.
So
this
was
the
proposed
text
that
was
put
on
the
list.
This
is
what
we're
gonna
add
to
the
to
the
draft.
Basically,
saying
hey,
you
know
if
you
send
unknown
unrecognized,
headers
or
unrecognized
layers,
you're
going
to
get
back
a
ICMP
parameter
problem
code,
one.
M
J
M
N
J
J
So
we've
had
this
request
from
Fred
I
think
since
the
last
IETF
about
adding
a
reference
to
RFC
1
122
I'm,
not
a
fan
of
this,
just
because
I
think
that
that's
pretty
old
and
I,
we
can
put
it
in
there
as
an
informational
reference.
If
people
feel
super
strong
about
this,
but
his
yellow
one
is
requested
at
this
point.
I
don't
know
if
anybody
else
feel
strongly
about
this.
O
For
a
template
from
Boeing
I'll
just
say:
there's
precedences
for
doing
this,
like
RFC
8200
cites
791
in
the
first
paragraph
of
the
document
and
for
ta
61
sites
are
very
early
on
in
the
document,
so
for
backwards
compatibility
and
for
reference.
The
old
protocol
I
think
that
would
be
appropriate
right.
J
O
C
Just
to
clarify
the
reference
to
the
ipv4
spec
in
80,
200
is
for
there
for
a
very
particular
reason,
which
is
to
sort
of
point
to
how
bits
on
the
wire
are
sent.
So
I
mean
it
wasn't
just
added
for
any.
It
was
done
for
that
exact
reason,
and
so
I'm
not
sure
I
understand
why
we
would
want
to
do
this
here.
O
C
J
Okay,
so
you
know,
we've
sort
of
been
avoiding
this
issue
as
much
as
humanly
possible
on
this
draft.
The
updating,
DHCP
verse,
RA
options
text
we
made
some
minor
updates
to
it
and
basically
we're
leaving
it
essentially
the
same.
You
know
we
could
obviously
expand
on
this
in
a
lot
of
different
ways.
At
the
moment,
we've
left
it
at
that.
You
know
you
here
are
the
RA
options.
J
G
J
F
Sorry
I
almost
timed
out
so
that
not
this
tech
specifically
I,
don't
know
if
you're
gonna
address
it
later
Loren's.
Indeed,
there's
there's
a
there's
a
should
for
dhp
stateful
address
assignment
I.
Don't
know
that
you're
gonna
discuss
that
later
or
no.
F
We
should
say
something
about
the
anime
newbie
profile,
I.
Think
in
the
sense
that
the
anonymity
profile
says
that
a
host
at
once
anonymity
should
prefer
a
stateless
to
stateful,
but
no
RFC
allows
it
to
say
I,
don't
want
to
connect
I,
never
want
to
do
stateful,
because
there's
this
shirt
I
mean
they.
F
Basically
it
says
you
should
do
the
HP
v6
and
so
the
network
should
basically
what
we're
saying
is
the
network
should
be
able
to
ask
you
to
sorry
what
we're
saying
is
that
if
the
network
asks
you
to
do
the
HP
v6,
you
should
do
it
and
the
anonymity
profile
simultaneously
says
you
given
the
choice,
you
should
prefer
stateless
over
stateful
address
configuration,
so
we're
kind
of
saying,
like
you,
should
give
up
your
privacy
when
asked
and
and
I
think
you
know,
maybe
we
should
have
a
little
bit
more
nuance
text.
There.
F
That's
in
the
text
of
this
document
I
give
that
sorry,
that's
in
the
text
of
1744.
It
says
you
do
staple
sorry
if
I
recall
correctly,
and
we
can
easily
check
this.
The
text
of
seven
eight
four
four
says
whether
you
do
stateful
a
stateless
address.
Auto-Configuration
depends
on
the
emaan
obits.
That's
what
I
recall
from
seven
844.
Somebody
can
quickly
check
it,
but
that's
what
I
recall
and
what
it
says
is
you're
supposed
to
do.
The
what
the
network
tells
you
to.
F
It
also
says:
if
you
have
a
choice
for
first
stateless
and
that's
you
know,
that's
reasonable,
but
now
here
we're
saying
like
you
should
do
the
HPV
6.
You
should
support
the
HPV
6,
so
it
kind
of
takes
away
your
choice
to
say,
like
I,
never
want
to
do
stateful,
because
it's
bad
for
privacy,
so
yeah
so.
G
G
M
F
J
That
I
mean
there's
reasons.
It's
a
should
right.
This
could
clearly
this
clearly
falls
into
the
category.
If
someone
wants
to
do
you
know
that,
that's
why
they
would
do
it
and
I
so
I'm
more
than
happy
to
put
the
text
in
there
saying
hey,
go,
go,
read
that
go,
read
the
Amana
MIDI
profile
for
the
privacy
stuff.
If
you
really
care
about
this,
you
know
we
can
absolutely
put
a
pointer
in
there
for
this.
G
Suresh
krisshnan
again
so
I
I
think
it's
too
simplistic
Lorenzo
right,
because
you
could
also,
if
your
privacy
sensitive,
you,
can
also
randomize
your
MAC
address
and
get
a
DHCP
address
right,
for
example,
I'm
just
like
pointing
is
that
I
was
at
an
example
that
why
this
is
not
simply
okay.
Reading
the
70
is
your.
P
G
Q
F
J
J
J
F
J
R
S
G
Last
point
on
this:
I
don't
drag
this
further,
but
the
M
bit
says
like.
If
you
read
it
carefully,
it
says
manage
address
configuration
is
available.
There's
nothing
telling
you
to
go
and
do
it
like,
so
that
correct
exactly
okay,
okay,
so
nobody's
telling
you
to
do
stateful
address
configuration.
That's
like
nothing!
We
have
a
mechanism
to
quota
people.
The
only
mechanism
we
have
is
to
not
make
addresses
available
photo
config
right.
Okay,
so
that's
not
saying
I,
don't
see
what
more
we
can
put
in
here.
But
if
you
have
text
like
you.
J
Okay,
so
here's
a
fun
topic,
so
it
was
suggested
this
week
that
we
look
into
this
is
based
on
the
ipv6
hackathon
right
and
the
general
gist
here.
Why
we,
this
document,
might
care
about
it
is
there
there
are
two
ways
to
do
some
of
this
nat64
prefix
discovery.
Also,
the
synthesis
of
ipv6
addresses
where
it
might
bad
offers
no
requirements
is,
we
might
want
to
add
some
of
this
into
the
if
it's
coming
from
the
OS,
this
would
be
a
good
place
to
put
it
if
we
think
applications
are
going
to
do
it.
J
I
I
K
I
This
day
and
age,
where
both
sockets
and
other
a
lot
of
other
efforts,
it's
not
the
case
anymore,
like
on
modern
operating
systems.
You
can
ask
for
connection
to
a
hostname,
and
this
is
done
by
the
OS,
but
it's
still
in
the
application
process.
Bay
so
I.
Think
if
we
want
to
tackle
this
question,
we
need
to
decide
were
what
we,
how
we
define
these
terms.
Okay,.
J
E
Q
Yes,
this
is
Alexander
Petrescu
I
may
be.
This
is
a
minority
opinion,
but
I
was
very
much
tempted
to
read
this
slide
and
discussion
in
the
documents.
When
I
see
the
title
ipv6-only
host,
the
temptation
comes
from
the
fact
that
I
did
perform
on
some
tests
on
a
separate
environment,
on
what
I
call
ipv6
only
hosts,
and
these
are
P
v6
only
hosts-
don't
have
ipv4
on
them,
whereas
here
it
seems
like
there
is
still
some
ipv4,
so
I
think
I
have
a
problem
until
now.
So.
E
Q
T
We
have
a
draft
on
the
terminology
and
v6
ops
that
got
torn
to
shreds.
Yesterday
I'm
telling
you
there's
a
difference
of
a
capillary
problem
here,
so
I.
Don't
think
that
we
should
put
this
in
the
notes
requirements
document
all
right,
because
it's
because
I,
don't
think,
should
be
a
requirement.
I
think
there
are
lots
of
places
where
we
have
v6
only
networks
that
are
v6
only
there
is
no
connectivity
to
anything
on
before,
and
a
v6
and
a
node
shouldn't
require
connectivity
to
a
protocol.
It's
never
going
to
use
further.
T
E
T
Your
laptop
now
v6
packets,
so
two
things.
If
you
want
to
argue
the
draft,
then
you
should
probably
do
that
from
here
and
not
there,
which
drop
we
don't
have
them,
which
draft
the
draft
were
discussing
so
you're
defending
a
proposal
that
should
go
about
whether
it
should
go
in
the
draft.
As
a
working
group
chair.
E
E
E
T
E
T
G
Ok,
so
can
I
suresh
krisshnan
to
clarify
for
lis?
Okay,
so
the
the
dns64
right,
it's
a
man
in
the
middle
okay
and
DNS
SEC
is
there
to
stop
man
in
the
middle,
so
the
only
way
DNS
SEC
would
work
with
an
@
6
4
system
is
if
the
host
can
synthesize
the
quad-a
by
itself.
So
do
we
want
to
do
that
or
not
right.
B
Q
Q
Q
C
J
F
So
before
I
start
speaking
as
somebody
close
to
me
that
do
they
have
a
clue,
bat
that
they
can
hit
me
with
okay.
So
if
that's
at
the
ready,
so
let
me
see
if
I
understand,
because
I
didn't
before,
regardless
of
points
one
and
two,
what
I'm
trying
to
I'm
trying
to
understand
the
slide.
Is
it
the
case
that
if
you
want
to
do
DNS,
SEC
validation
and
you
want
to
work
on
a
dns64
network,
you
must
support
the
points.
That's
the
case
right.
D
F
F
E
F
F
Stack,
you
don't
want
to
allow
apps
to
open
a
v4
socket.
If
you
don't
want
to
connect
to
v4
literals,
you
don't
need
to
do
the
first
two
ever,
but
but
most
most
hosts
run
things
that
do
use
today.
But
if
I
want
to,
if
I
want
to
write
a
new
operating
system
that
doesn't
support
the
socket
call
and
doesn't
support
a
fi
net,
I
don't
need
to
do
the
first
two.
But
if
I
want
to
do
the
third
one,
then
I
have
to
do
the
first
two
as
well.
There
yeah.
P
F
So
then
maybe
it
should
be
written
like
this
right.
You
don't
have
to
do
the
first
two,
but
if
you
want
to
do
DNS
SEC,
you
have
to
know
that
it
doesn't
work
on
a
dns64
network
and
you
should
support
that
because
otherwise,
like
you
got
our
DNS
SEC,
you
got
a
damn.
If
you
say,
you've
got
a
DNS,
SEC
resolver,
and
now
you
can't
work
on
dns64
networks,
which
is
really
bad.
That
make
more
sense.
So
it's
basically
like
four
in
the
furnace.
The
last
point
should
be
the
first
one.
F
F
J
S
Name
is
Kevon
of
italian
telecom.
This
draft
is
about
the
requirements
of
ipv6
node.
It
seems
that
right
now,
many
folks
on
the
computer
system,
broadband
network,
but
I,
think
it
is
it's
better
to
consider
another
kind
of
a
basic
device
that
is
IOT
device
right
now
we
have
begun
to
deploy
some
MB
IOT
device
by
ipv6,
but
it
has
different
requirements
to
to
activate
to
activist
capabilities.
For
example.
S
J
G
U
G
That's
where
the
profiling,
like,
so
the
smaller
set
of
things,
is
being
done.
So
if
you
go
to
6,
low
or
6
or
LP
ran,
you
would
see
the
smaller
profiles
for
constraining
nodes.
So
this
is
like
a
generic
v6,
not
requirements
and
there's.
If
you
look
at
a
3gpp
know,
like
Tim
says
they
have
a
smaller
set
of
these
things
or
BBF
right,
like
routers,
will
have
a
smaller
set
of
things.
G
I
Danskin
Ozzy
Apple,
so
this
document
is
about
requirements
for
ipv6
hosts
and
the
goal.
If
my
understand
please
correct
me,
if
I'm
wrong
of
this
document
is
that
when
people
who
make
devices
put
them
on
an
ipv6
network,
they
can
interoperate
that's
what
six-man
does
we
define
the
protocols
and
we
make
sure
that
this
is
the
case.
I
Nat64
dns64,
talking
to
literal,
ipv4
host,
sorry
I
talked
to
happy
before
literals
is
not
a
requirement
to
be
able
to
communicate
over
ipv6
in
any
way
shape
or
form.
That's
an
operational
decision
like
the
fact
that
we're
at
a
Paul
wrote
support
for
doing
these
things
is,
was
an
operational
concern
that
yeah.
If
someone
wants
to
go
in
Safari
and
type
in
ipv4
address,
we
wanted
that
to
work,
but
that
wasn't
a
requirement
for
us
to
be
over
ipv6
and
we
have
a
working
group
for
that.
That's
v6
UPS.
I
We
have
documents
for
how
to
do
these
things,
which
are
it's
chartered
for
that,
and
we've
actually
made
progress
selectors
for
exactly
these
problems
like
happy
eyeballs
version
2
talks
about
how
we
do
these
things
when
it
comes
to
DNS
SEC.
What
is
this
even
doing
here
are
supporting,
like
you
know,
guidance
on
how
DNS
second
dns64
interoperate
is
a
great
thing
to
have
I
really
don't
understand.
I
V
V
J
J
V
J
U
Son
bomb
cake,
thank
you,
barber
Stark,
so
the
way
I
use
this
the
current
RFC
is
every
single
must
that
is.
There
must
apply
to
every
ipv6
capable
node
that
goes
into
my
home,
every
darn
one
of
them.
There
must
not
exist
a
single
use
case
for
any
device
to
not
do
that.
Must
that
suggests
that
this
is
not
a
must,
because
we've
already
heard
a
number
of
use
cases
where
these
do
not
apply
now
in
broadband
forum.
U
It
was
mentioned,
though,
I
have
take
made
use
of
this
document
by
sometimes
elevating
a
should
to
a
must
for
my
particular
use
case,
and
that
is
as
it
should
be,
and
there
that's
exactly
the
way
I
think
you
know
should
should
be
used.
Is
that
when
you
have
a
use
case
where
it
should
becomes
a
must,
then
you
describe
that
use
case,
and
you
describe
that
in
this
use
case.
This
should
is
a
must.
That
was
it.
Thank
you.
R
E
J
Coming
out
from
interns
I'm
with
you,
so
this
is
the
last
thing.
This
document
it
was
informational
and
we're
suggesting
that
maybe
we
should
make
it
best.
Common
practice
does.
J
Strong
feelings
about
this
I
think
we've
talked
about
this
a
couple
of
times,
but
since
we're
getting
close
to
working
group
last
call
probably
we'll
switch
it
over
to
best
BCP
on
before
we
submit
it
unless
people
are
really
opposed
to
that,
all
right
sounds
good
to
me
right.
So
you
know
I
think
we
got
consensus.
Almost
everything
we
presented
today.
It
was
up
on
that
list,
so
I
think
we're
getting
close
to
working
group
last
call
so.
E
J
E
Yeah,
but
should
we
try
to
get
more
review
in
the
working
group
now
perhaps
use
the
issue
tracker
to
to
track
the
last
remaining
issues
and
then
yep
yeah?
Could
we
get
a
couple
of
volunteer
reviewers
for
this
document
by
the
way,
because
it
is
a
40
page
document?
It
would
require
some
time,
but
it
would
be
very,
very
good
that
we
go
through
this
as
well
as
we
can,
and
we
avoid
any.
You
know
issues
later
on
in
the
process,
because
there's
lots
of
opportunity
to
get
things
wrong
here.
E
So
this
is
a
problem,
came
up
where
we
realized
that
someone
else
had
taken
Bates
out
of
the
reserve
field
in
a
previous
information
option
in
their
advertisement
from
48
61,
and
this
happened
when
someone
else
wanted
to
have
a
flag
from
there,
and
we
realized
that
we
had
no
central
repository
over
those
flags
and
the
problem
was,
if
the
the
expert
they
won't
do
this
one.
They
discovered
that
in
sixty
to
seventy-five,
it
actually
taken
another
flag
after
this,
this
reserve
field.
E
So
what
this
draft
us
is
just
create
a
new
Ayana
registry
for
the
set
of
bits
in
the
reserve
field
in
the
prefix
information
option,
not
that
we're
expecting
a
lot
of
use
of
this,
but
at
least
now
we
have
a
central
place
where
these
flights
are
defined.
So
the
document
does
update
48
61.
It
does
not
update
6
to
75
I
mean
the
problem.
E
Here
was
the
60
to
75,
didn't
update
48
6
to
1,
and
there
was
a
relatively
long
thread
of
the
correct
use
of
update
and
we
don't
want
a
rathole
into
that
one.
But
the
district
4
pages
creates
a
new
I
and
a
consideration
section
that
that's
it
it's
currently
an
individual
draft
I
would
like
it
adopted
and-
and
you
know
last
call
pretty
quickly
if
you
think
this
is
the
right
way
of
doing
this.
Any
any
comments
on
this
one
Lorenzo.
F
G
Q
G
Yeah
so
a
couple
of
things,
so
there
is
some
stuff
to
be
done
here
for
sure
and
it's
not
specifically
a
problem
about
this
flag.
So
there
there's
I,
think
some
general
work
also
needed,
and
it's
probably
somebody
else
has
to
do
this.
Ok,
I'm,
not
like
wanting
you.
Do
this
I'm
fine
with
this
draft
and
it's
I'm,
okay
with
it
going
forward,
but
we
have
a
general
issue
with
updates
in
the
ITF
and
general
issue
with
flags
in
the
ITF.
K
T
T
E
I
would
be
happy
to
change
that,
so
it
does
have
a
Jin
general
problem
in
the
IKEA
40.
What
does
reserved
fields
actually
mean
and
all
right,
and
would
you
need
to
have
Ayana
registries
for
all
of
them
before
we
even
started
using
them?
There's
a
whole,
but
that's
not
as
something
six
Mac
and
can
resolve
and
the
only
solution
we
found
was
doing
it.
This
way
I
mean
we
went
through
the
whole
list
of,
should
we
do
in
our
art
or
should
we
do
something
else
right.
G
So
what
happens
to
implementations
that
don't
read
the
flag
and
see
does
not
zero
right
so
that
can
this
is
a
really
really
deep
rat
hole
and
I
think
it
needs
to
get
fixed,
irrespective
of
what
happens
with
the
slack
stuff,
but
I
think
it's
good
to
start
with
it
with
this
one.
But
if
we
do
this
on
this
way,
you
don't
see
any
problems
with
the
iesg.
This
rat
hole
will
not
spin
out
of
control.
F
R
G
Just
to
go
back
into
the
policy
stuff
so
like
this
Thresh
answering
to
Michael
what
I
said
with
other
Mike,
so
the
standard
section
will
preclude
experimental
RFC's
from
taking
a
bit
slack.
So
if
you
want
experimental
stuff
to
take
this,
then
the
action
needs
to
be
different.
The
policy
needs
to
be
different,
something.
G
Define
an
experimental
bit
but
I,
don't
know
if
we
want
to
do
like
IETF
consensus
could
be
like
another.
It's
another
policy
which
would
let
you
go
through
the
ITF
process
in
whatever
way
to
get
it
right,
luck
would
be
experimental,
so
there's
like
different
policies,
I
think
it's
like
82
26,
like
defines
it.
What
are
30
26
based
I,
don't
know
what
the
number
is
like
behad,
but
I
think
you
save
you
26.
Q
E
W
C
Okay,
so
it
seems
like
their
support
for
this,
but
I,
don't
why
don't
we
do
a
hum
for
adopting,
as
a
working
group
document
will
confirm
it
afterwards
on
the
list.
So
if
you
support
this
as
a
working
group
document,
please
hum
very
loud.
If
you
don't
support
it,
okay,
I
think
we
can
call
that
support
will
confirm
on
the
mailing
list.
Thank
You,
Olli,
okay,.
L
L
L
There's
another
thing
that,
according
to
49:41,
the
same
interface
at
ease
mode,
is
employed
for
multiple
prefixes.
So,
for
example,
in
the
same
the
same
local
network,
multiple
prefixes
are
announced,
all
of
them
will
be
used
in
the
same
interface
ad,
which
obviously
allows
for
the
correlation
of
network
activity.
L
Another
thing
is
that
these
interface
identifiers
are
generated
over
time
and
there
are
implementations,
actually
that's
what
the
spec
says
that
they
move
from
one
network
to
another
and
they
still
use
the
same
interface
identifier.
So
it's
generated
over
time,
so
you
generate
one
identifier.
Now
you
employ
it
for
the
local
network,
your
notes
moved
from
one
network
to
another
and
you
still
use
the
same
interface
identifier,
okay,
so
that
allows
for
the
correlation
of
network
activity.
L
Even
when
you
move
from
one
neighbor
to
another,
all
the
things
is
the
according
to
49-41,
there
are
limits
on
the
number
of
non
deprecated
addresses,
meaning
that
at
any
point
in
time
you
should
only
be
using
one
temporary
address,
that's
a
limitation
and
we
well.
There
are
other
mineral
issues
in
the
these
are
the
main
ones.
L
So
what
we
try
to
do
in
this
document?
First
of
all,
we
try
to
do
something
similar
to
what
we
did
with
stable
addresses,
which
is
start
with
security
and
privacy
requirements
for
the
temporary
addresses.
What
are
the
properties
that
these
addresses
should
have
then
suggest
some
possible
algorithms?
These
algorithms
are
not
mandatory,
so
you
can
do
your
wrong
way.
This
is
just
if
you
don't
have
a
better,
better
option.
You
can
pick
one
of
these
algorithms
to
comply
with
their
requirements.
L
Third
thing
is
to
clarify
it
that
temporary
addresses
only
are
allowed
so
so
far.
You
know
this
point
in
time.
If
you
work,
if
you
generate
temporary
addresses,
you
are
also
required
to
configure
stable
addresses.
So
what
we
want
this
document
to
do
is
to
say
that
it's
also
okay,
if
you
only
want
to
use
temporary
addresses-
and
the
last
bit-
is
something
that
we
talked
among
the
the
authors.
L
You
know
how
this
document
would
fit
with
49:41
and
the
conclusion
that
we
got
to
that
is
probably
the
better
option
is
to
have
this
document
obsolete,
49:41,
the
reason
being
the
issues
that
were
mentioned
in
the
previous
slide.
Okay,
as
a
kind
of
summary
of
their
requirements
for
the
this
non,
stable
or
temporary
interface
at
ease,
is
that
obviously
they
have
to
have
a
limited
lifetime.
Obviously
they
are
temporary.
We
also
know
that
lifetime
must
be
reduced
or
further
reduced
by
security,
meaningful
events.
L
This
could
be
like
moving
from
one
network
to
another,
meaning
that
the
case
that
I
mentioned
before,
in
which
you
generate
a
random
interface
identifier
and
you
move
from
one
network
to
another,
would
make,
for
example,
the
interface
I
need
to
change,
and
obviously
there
are
a
number
of
issues
here
that
are
not
issues.
There
are
a
number
of
other
security,
sensible
events
that
might
trigger
the
regeneration
of
interface
identifiers.
The
other
thing
is
that
they
must
be
different
for
different
prefixes.
L
So
let's
say
if
two
prefixes
are
announced
on
the
same
network,
you
shouldn't
use
the
same
interface
ID,
because
otherwise
it's
possible
to
correlate
neighbor
activity
between
those
two
prefixes.
They
must
not
embed
layer.
2
addresses
they
must
be
difficult
to
predict
by
I,
know
an
outside
entity
or
party
that,
obviously
you
don't
want
these
IDs
to
be
predictable
and
the
last
one
is
that
they
must
be
semantically
opaque,
that's
obviously,
based
on
on
current
standards.
L
What
we
mentioned
for
non
stable
interfaces,
these
four
algorithms.
Well,
first,
one
is
just
get
a
random
number.
You
use
whatever
I'll
go
algorithm
you
have
for
generating
random
numbers.
Another
possibility.
Could
be
the
use
of
an
expression
that
is
similar
to
the
one
that
we
use
in
72
seventeen
for
stable
addresses.
It
just
has
like
a
minor
modification.
L
First,
we
have
a
time
value
over
there
so
that
they
do
change
over
time
and
in
this
particular
case,
what
we
did
is.
We
also
include
the
MAC
address,
so
in
72
seventeen,
this
is,
let's
say,
an
abstract
parameter,
which
is
the
network
network
interface.
But
in
this
case
we
include
the
MAC
address,
because
we
want
to
make
sure
that
if
you
are
randomizing,
the
MAC
addresses
well,
when
you
change
or
you
randomize,
a
new
MAC
address.
Also
the
interface
IDs
for
ipv6
addresses
change.
Q
L
L
Mac
address,
and
in
that
case,
if
we
assume
that
you
know
the
node
is,
for
example,
randomized
in
the
MAC
address.
Well,
it's
this
problem
is
actually
tied
to
what
the
node
does
about
my
calluses.
If
you
are
doing
MAC
address
randomization
when
you
actually,
you
know,
connect
to
a
different
network,
your
MAC
address
should
be
changing
and
if
the
MAC
address
changes,
you
should
also
change
the
ipv6
address,
but.
Q
F
L
The
thing
is,
there
are:
if
you
look
at
49:41
there
are
things
like,
for
example,
even
if
you
had
a
single
prefix,
there
are
lots
of
things
that
you
should
watch
in
49:41
example.
You
generate
the
random
interface
identifier,
but
over
time
you
generated
one
random
identifier.
Now
you
move
to
a
different
network.
You
reuse
the
same
random
identifier,
so
what
we
were
talking
with
our
co-authors
is
that
if
you
were
actually
to
try
to
fix
the
issues
that
we
form
in
49:41
I
mean
the
document
would
be.
L
You
would
end
up
patching
the
document
in
so
many
different
places
that
it
doesn't
make
sense.
So
you
could
say
that
you
might
try
to
do
improvements
to
49:41,
but
at
the
time
that
you
try
to
address
the
issues
that
are
described
here,
the
patches
would
be
so
many
that
I,
you
probably
move
away
from
that
algorithm.
The.
F
Reason
I
ask:
is
that
there's
a
lot
of
stuff
in
49:41
that
is
now
going
to
deleted?
If
we,
if
you
deprecated
it,
for
example,
it
tells
you
how
to
generate
new
addresses
if
you
get
a
dad
failure
right.
All
that
stuff
is
is
is
in
there
and
it
was
you
know
it's
operationally
proven
right.
So
you
know
I,
don't
know
that
we
want
to
like
throw
it
out
completely.
That's.
L
I
mean
that's
something
that
I
mean
we
talked
I'm
on
the
co-authors
and
there
are
possible
ways
forward.
For
that
I
mean
the
thing
is
that
if
you
want
to
keep
49-41
as
an
option,
they're
still
like
lots
of
things
in
the
document
that
should
be
patch
I'm,
not
saying
that
you
know,
that's
not
a
possible
way
forward.
What
we
thought
that
I'm,
not
sure
it
makes
sense
to
do
that.
So
another.
C
L
C
Q
L
L
Among
you
know,
we
co-authors
I
mean
there's
a
lot
of
like
a
lot
of
what's
in
I,
mean
there's
a
lot
of
details
about
the
general
viruses
that
you
know
that
we
might
keep
regarding
Timon
and
so
on.
But
what
we
kind
of
like
think
and
talk
with
a
co-authors
is
that
at
the
time
you
tried
to
address
the
issues
that
we
have
here.
The
changes
would
be
rather
fundamental
to
49-41,
so
there
wouldn't
be
much
of
a
difference
like
starting
from
a
from
scratch.
G
Suresh
krisshnan
it
a
hat
on
and
49-41
hat
off
right
like
so
specifically
want
to
say
something
so
49:41
is
a
product
of
this
working
group
or
something
that
preceded
it
right,
and
that
was
done
at
a
time
where
the
internet
environment
is
different.
Okay,
so
we
didn't
have
this
pervasive
monitoring.
We
didn't
have
this
kind
of
tracking
and
everything,
so
it
was
done
to
a
different
set
of
things
and
I.
Think
it's
the
working
group
job
to
maintain
its
specifications
so
and
I
do
see,
understand
what
I
see
like
but
I
see.
G
G
So
the
working
group
needs
to
decide
which
way
it
needs
to
go,
and
if
the
working
group
decides
that
for
941
base
is
the
way
to
go
right,
it's
the
way
to
do
it
and
the
content
of
49:41
base
is
whatever
the
working
group
decides.
It
should
be
right
and
at
some
point
you
need
to
think
about
back
of
it
compatibility
right.
G
G
Yes,
okay,
so
disagrees,
but
like
okay,
so
I
I
think
this
is
not
a
technical
decision,
so
you
talk
as
if
there
is
like
a
big
technical
difference
between
funny
and
for
you
on
this
and
this
but
I
think
it's
not
the
or
our
document.
We're
gonna
end
up
with
right.
Whatever
is
ideal
document
right
within
your
multiple
algorithm
support
and
everything
can
either
be
called
for
unit
for
your
own
base
or
something
else
right
and
I.
G
Think
that's
the
working
groups
decision
how
that
goes
so
that
I'll
support
whatever
the
working
group
does
right
doesn't
make
sense.
Like
you
know
what
I'm
saying
is
it's
not
a
technical
decision
because
you,
like
you
know,
441
has
one
algorithm.
Of
course
it
does
right,
but
doesn't
mean
funding
for
your
own
business.
You
have
one
algorithm,
that's
the
power.
I
was
trying
to
make
the.
L
G
There's
a
bunch
of
things
in
front
in
41,
right,
yeah,
okay,
so
there's
some
things.
That's
in
this
draft,
some
things
that
need
to
get
added.
Okay,
if
you
take
whatever
document
you
take
his
base,
you
take
for
941,
it's
not
ideal!
You
take
your
document,
it's
not
ideal.
They
both
mean
it's
not
ideal
right.
G
No,
but,
like
you
know,
learnings
are
just
part
of
something
right
like
you
know,
Dad
failure
like
you,
keep
regenerating
right,
that's
missing!
So,
at
whatever
you
start
off
it,
you
need
to
improve
it.
What
the
document
is
called
is
not
material
personally
for
me,
yeah
right
and,
as
I
said,
if
the
working
group
decides
to
take
that
are
upright,
like
they
need
to
I,
really
want
that
to
obsolete
49-41
period.
Right
like
if
we
decide
like
for
941,
it's
not
good
enough
for
the
environment
of
today.
G
L
Part
of
what
this
document
tries
to
do
is
to
apply
both
things
a
bit.
If
you
go,
for
example,
where
was
it
ad
64?
They
want
the
requirements
for
stable
addresses.
What
that
document
does
is
specify
requirements
for
stable
addresses,
and
then
you
get,
for
example,
in
that
case,
it's
in
a
different
document
to
find
algorithms
or
possible
algorithms
that
can
comply
with
those
requirements.
So
in
a
sense
I
mean
this
document
does
contain
some
sample.
L
Algorithms
does
contain
some
sample
organism,
but
at
the
end
of
the
day,
it's
an
abortion
or
something
similar
to
1864,
but
for
non
stable
addresses.
For
example,
they
algorithms
themselves
could
be
moved
out
of
the
document.
I'm
not
saying
that
that's
our
plan
but
say
it
could.
So
this
document
in
that
sense
is
the
equivalent
28064,
but
for
temporary
addresses
like
set
requirements.
Then
how
you
actually
comply
those
requirements,
for
example,
it
could
be
something
like
along
the
lines
of
49-41.
G
L
And
actually,
what
we
have
right
now
is
some
on
one
hand.
Actually
there
was
a
version
that
you
know
we
didn't
get
to
post,
but
what
we
do
right
now
in
the
document
is
specify
the
set
of
requirements
and
then
say:
if
you
want
to
let's
say,
comply
with
these
requirements,
then
these
are
possibilities
like
I
think
that
in
the
version
that
is
posted
right
now,
we
even
have
49-41
as
one
of
the
possible
algorithms
modular
addressing
the
things
that
we
have
here.
L
Okay,
so
it's
listed
as
one
of
the
possible
algorithms
and
that's
something
that
we
were
discussing
among
co-authors
like
what
to
do
so.
Let's
say
one
possibility
to
was
to,
for
example,
mention
a
couple
of
algorithms
and
then
also
point
to
a
Patchett
version
of
49:41.
Okay,
another
option
was
to
include
those
all
the
possible
algorithms.
In
there
I
mean
that's
open
for
input
and
as.
L
It's
this
is
open
for
input
like
I,
understand
that
the
working
group
might
say
well,
it
is
okay
to
specify
their
requirements,
but
we
want
to
do
the
algorithm
cells.
Were
that's
a
possibility
too.
K
F
We
wrap
49-41
fix
the
bugs,
and
then
we
generalize
that,
because
it's
good
there's
a
lot
of
there's
a
lot
of
good
stuff
inside
for
you
I'm
41,
and
so
it's
like
how
do
you?
How
do
you
product
Liege
ener,
ate
them?
How
often
you
have
to
change
them?
The
fact
that
you
have
to
keep
the
old
ones
around
all
that
stuff
is
really
valuable.
It's
very
important
to
keep
and
we
shouldn't
like
throw
that
out.
F
Just
because
it's
old
we
yeah,
there's
bugs
it
says
like
use
whatever
rc4,
okay,
that's
obsolete,
it
says
or
whatever
it
is
like.
You
know,
but
like
it's
it's
you
know,
so
we
should
fix
it
and
then,
if
we
want
to
do
something
more
as
like
do
something
more
general
personally,
like
I,
feel
like
the
ID
is
up
to
the
host
period.
F
Like
that's
what
you
do
right,
but
then
we
also
have
to
say:
well,
don't
do
something
dumb,
like
always
pick
one,
don't
do
something
dumb
like
see
your
random
number
generator
with
the
with
the
time
at
which
you
you've
joined
the
network,
because
then
I
can
predict
everything
if
I,
if
I
guess
properly
right.
So
so
these
things,
you
know,
I,
think
we're
better
off
doing
49:41
this
and
then
generalizing
it.
F
If
we
don't
do
it
that
way,
then
we
have
to
be
very
careful
and
say
that
one
of
the
goals
of
this
exercise
is
to
ensure
that
everything
that
49-41
does
today
will
still
be
done
in
an
implementation
of
this
new
document.
So
either
way,
like
actually
I,
said
either
way,
but
we
do
need
to
keep
that
stuff
around.
How
do
you
say.
F
L
F
F
C
W
Drink
use.
The
quick
command
in
the
same
vein
is
Lorenzo.
There
are
some
things
in
the
current
draft.
Then
they
say
network
connect
disconnect.
Is
it
kinda
funny
I?
Do
you
think
it's
no
they'd
go
in
sleeping
mode
and
quit
the
sleeping
mode?
Is
it
a
new
connect,
if
so
I'm
little
bit
concerned
that
we
end
up
with
too
many
addresses
cuz.
That's
nice
for
the
host,
but
for
the
routers
is
a
cache
and
in
some
case
for
security.
We
keep
a
lot
of
state.
F
Eric
Cline
I
was
actually
gonna,
say
the
same
thing
everything
he
just
said
and
there's
a
deployment
section
in
49
41,
which
has
be
discovered
as
I
was
as
it
was
made
known
to
me
in
v6
ops,
section
3.6
says
you
must
be
able
to
disable
these
privacy
addresses,
which
I
think
we
should
like
yeah
yeah
yeah.
It
said
we
should.
F
We
should
make
that
it
should
and
and
one
of
the
things
that
you
can
include,
if
you
revise,
if
you
do
a
49-41
this,
that
you
can
rewrite
the
deployment
section
to
be
more
sane
and
include
things
like
if
the,
if
you
don't
have
the
whole
slash
gt40
yourself,
then
be
careful.
You
don't
flip
over
into
promiscuous
mode
and
stuff
like
that.
Okay,.
L
L
L
You
might
so
I'm
not
saying
that
we
is
something
that
we're
pushing
or
recommending,
but,
for
example,
if
you
want
to
use
a
new
address
for
a
new
connection
or
product
or
a
processor
whatever,
that
is,
it's
not
possible
to
actually
have
it's
not
possible
to
actually
achieve
that
implications
of
that
limitation.
Is
that,
obviously
you
know
the
more
you
use
an
address,
of
course
that
allows
for
a
correlation
of
neighbor
activity.
So
that's
when
it
comes
to
outgoing
connections,
then,
when
it
comes
to
incoming
connections,
there
are
other
problems
like,
for
example.
L
Right
now
is
not
possible
to
specify
what
are
the
properties
that
you
want
for
the
addresses
on
which
you
listen
for
incoming
connections.
The
typical
practice
is
that
when
you
are
coding
an
application,
essentially,
you
know
you
use
the
Wilker
address
in
vine,
meaning
that
any
address
that
is
configured
on
the
local
node
can
accept
incoming
connections.
There
are
a
number
of
issues
for
that.
L
L
If
you
have
a
public
address
to
the
public
internet
and
then
there
are
other
things-
and
this
is
something
that
don't
remember
the
name
of
the
guy,
but
was
something
that
was
discovered
in
the
well
in
which
let's
say
that
you
have
a
device
and
it
has
temporary
addresses.
Well,
it
was
phone
in
the
world
that
this
device
connects
to
the
internet.
It
employs
some
kind
of
like
service,
but
when
you
employ
that
service,
then
that
exposes
one
of
your
addresses
right
now.
L
The
same
address
the
same
temporary
address
that
you
use
for
using
or
for
performing
an
ongoing
connection
can
now
be
employed
to
contact
you.
So
in
this
particular
case,
I,
don't
know
if
you
have
read
about
it,
but
it
was
a
raspbian
system.
It
was
connecting
to
raw
NTP
server
and,
right
after
you
know,
using
NTP.
L
They
were
getting
a
poor
scan
by
you
know,
because
this
prague
server
was
actually
employing
the
temporary
address
for
that,
since
it's
not
possible
to
actually,
you
know
specify
the
properties
that
you
want
for
these
addresses
even
less
in
a
portable
way.
Well,
these
are
some
of
the
implications,
some
of
the
security
implications
that
we
have
in
the
previous
versions
of
this
document
we
tried
to,
or
we
were
meaning
to
provide
advice
in
this
area.
L
This
was
more
of
a
tool
thing
in
the
in
the
document
and
based
on
the
discussion
that
we
had
at
the
last
IETF
meeting,
we
agreed
on
having
the
document
just
focus
on
a
problem
statement
like
limitations,
that
we
have
right
now
in
the
hopes
of
actually,
you
know,
first
of
all,
rise
in
awareness,
for
example,
about
the
implications
of
their
properties
in
ipv6
services,
but
also
possibly
trigger
work
that
you
know
my
mitigate
these
issues.
So
the
document
right
now
is
actually,
despite
the
the
file
name.
E
They
here
one
person
already
so
two
to
three:
have
you
so
lost
lost
ITF?
Where
I
think
that
two
to
discussions,
one
was
that
we
didn
t
do
API
sand
and
Dave
Taylor
is
the
liaison
for
the
proposed
six
I
guess
suggested
you
two
should
sit
down
discuss.
You
know
how
to
do
with
the
API
I.
Guess
that's
where
it
moved
to
a
problem
statement.
E
The
other
discussion
we
had
was
you
know
this
likely
belongs
in
transport
and
there's
certainly
quite
a
lot
of
work
in
transport.
Right
now
you
know
API
sockets
and
things
were
where
these
considerations
belong.
Have
you
presented
this
in
transport
or
have
you
only
I
didn't
regard.
L
The
API
is
what
what
we
talked
with.
It
talked
with
Dave,
and
the
thing
is
that
we
don't
get
to
specify
like
api's
for
specific
languages,
but
we
do
get
to
specify
abstract
api's.
So
what
we
were
talking
with
a
was
that
I
mean
this
is
not
in
this
document,
because
this
document
is
not
meant
to
specify
anything,
but
where
we
talk
with
a
but
I
will
let
I
don't
know
if
Davis
here
but
I
mean
I.
L
Will
let
him
make
his
comment,
but
yeah
it
could
be
possible
to
do
like
an
the
specification
of
an
abstract
API
and
then
that
could
be
like
forwarded
or
try
to
be
taken
to
other
groups
there,
where
there
might
specify
like
a
language,
specific
API.
Those
language
specific
api's
are
certainly
outside
of
the
scope,
but
we
could
actually
work
on
an
abstract
API
like
if
you
want
to
specify
a
language,
a
specific
one.
What
are
the
functions
and
under
calls
that
you
might
that
you
should
be
supporting.
L
E
X
X
I
did
not
wish
to
respond
or
be
discovered,
and
you
don't
want
to
use
packet
filtering
in
the
kernel,
and
you
don't
want
to
use
external
protections
provided
by
the
ISP
restricting
flows.
You
want
to
have
an
API
flag.
That
says
when
I
said
any
address,
I
meant
any
address,
except
the
ephemeral
address.
For
instance,
you
want
to
have
conditional
flags
around
the
binding
qualities
for
listening
and
for
sending
that's
what
I
think
I'm
hearing
you
say.
That's.
X
Y
L
In
the
stack
yeah,
but
it's
there's
a
lack
of
an
API,
so
your
application
is
going
to
use
an
API
for
that.
There's,
no
undone
API
for
that.
X
O
So
the
document
was
first
posted
on
the
six
men
list
in
January
lists
comments
resulting
in
an
update
to
the
draft
and
was
presented
IETF
98.
We
had
some
more
comments
that
resulted
in
a
new
draft
version
presented
I
299,
and
then
they
were
updates
after
IETF
99
for
draft
so5,
which
is
the
current
version.
Here's
the
point
of
the
draft,
so
the
motivation
for
this
work
is
for
neighbors
to
be
able
to
share
routing
information
with
each
other
on
very
large
links
with
there's
many
nodes,
for
example
NB
MA.
O
We
want
to
be
able
to
support
direct
neighbor
to
made
neighbor
communications
at
layer
3
without
having
to
go
through
a
router
on
the
link
and
we
need
a
route
discovery
mechanism
on
links
where
traditional
routing
protocols
are
impractical,
for
example,
due
to
the
large
scale
and
the
solution
that
we're
looking
at
is
to
include
route
information
options
in
ipv6,
neighbor
discovery
messages,
so
route
information
options
in
41
91
were
specified
to
be
included
in
router
advertisement
messages
and
there
to
inform
the
recipient
of
more
specific
routes
that
are
reachable
via
this
router
RFC
4180
one
defines
three
different:
toasts
host
types,
a
B
and
C
types,
a
and
B
both
ignore
the
our
iOS
type
C
process.
O
Our
REO
is
only
in
our
a
messages
and
where
our
draft
is
doing
is
defining
a
new
type
of
host,
a
type
D
host
that
has
the
same
behavior
as
type
C,
except
that
also
processes.
Our
iOS
and
other
ipv6
neighbor
discovery
messages,
and
this
is
especially
useful
for
hosts
that
receive
prefix
delegations
for
tethering
or
multi
addressing
purposes,
and
we
have
related
drafts
that
talk
about
those
cases.
O
So
this
draft
is
updating
our
FCM
$41.99
to
include
our
iOS
in
any
ipv6
neighbor
discovery
message.
It
also
updates
RFC
49
191
to
include
a
solicit
bit
in
the
our
I/o
header,
so
nodes
include
our
iOS
in
neighbor,
solicitation,
router,
solicitation
messages
with
s
set
to
one
to
solicit
routes
from
neighbors
and
notes
include
REO
Zin,
neighbor,
solicitation,
router
solicitation
neighbor
at
hasn´t
router
advertisement
with
s
equals
zero
to
assert
routes.
That's
saying
this
is
a
route
that
I
have
and
I'm
asserting
that
to
you
that
this
is
my
route.
O
Routers
include
our
REO
s
and
redirect
messages
with
s
equals
zero
to
refer
to
other
routers.
So
if
you
have
a
source,
a
router
and
a
target
and
the
source
needs
to
go
through
the
router
to
get
to
the
target,
the
router
can
send
a
redirect
message
to
the
source
that
says
you
can
go
talk
to
this
other
guy
directly
without
having
to
go
through
me.
It's
backwards
compatible
in
that
types.
A
B
hosts
will
still
ignore
the
REO
s
and
neighbor
discovery
messages.
O
O
E
So
Fred,
if
you
go
back
to
slide,
oh
five
yeah
one
move
done
yes!
So
as
I
read
this,
the
draft
last
night
and
I
did
actually
come
around
a
bit
and
think
it
wasn't
the
you
know.
It
was
quite
a
good
idea,
but
I
couldn't
quite
get
was
what's
the
purpose
of
the
s
flag
and
combined
with
putting
this
in
in
other
messages,
I
mean,
could
you
just
get
away
with
doing
it
in
the
redirect
and
nowhere
else.
O
So
the
way
that
protocol
works
is
that,
when
a
redirect
message
goes
back
to
the
source,
the
redirect
is
going
to
be
saying,
go
talk
to
the
target
and
then
the
source
is
going
to
send
a
neighbor
solicitation
message
to
the
target.
With
that
s
bit
set
someone
that
says:
I
want
you
to
give
me
this
route
that
you're
holding
and
then
the
target
sends
back
a
neighbor
advertisement
with
an
REO
with
that's
bit
set
to
zero.
O
You
actually
have
this
route
right
to
two
things.
First
of
all,
the
router
has
no
knowledge
of
the
prefix
lifetime
of
the
target,
so
that
that
it
doesn't
have
any
way
of
telling
the
source
that
this
is
the
prefix
lifetime.
So
the
source
has
to
go
to
the
target
to
get
that
prefix
lifetime,
and
the
other
thing
is
the
NS
na
tests,
the
forward
path
to
make
sure
the
forward
path
is
working.
Before
you
start
sending
data
packets.
E
K
K
Incidentally,
there's
someone
on
this
network
who's
putting
out
IP
version,
4
broadcasts,
255.255.255.0
5,
although
it's
an
ipv6
only
network,
and
can
you
explain
a
little
bit
more?
What
scale
is
on
the
on
the
truly
NDMA
ones
and
what
technology
you're
talking
about
cuz
I'm
a
little
bit
confused
about
the
use
cases,
but.
O
Well,
just
taken,
for
example,
in
this
use
case
with
the
aeronautical
communications,
we're
talking
about
having
all
the
airplanes
worldwide
connected
to
an
NB
ma
link
and
that
airplanes
need
to
share
prefix
information
with
each
other
over
then
MB
emailing.
So
in
terms
of
scale,
thousands
of
nodes,
tens
of
thousands
and
nodes,
as
many
as
you
like,.
K
O
E
M
Right
right:
it's
not
the
answers
them
so
Eric,
not
Marc,
so
I'm
a
bit
concerned
about
the
security
implications
of
those
right.
So
right
now
I
mean
we
have.
We
have
our
a
guard
as
a
tool
that
prevents
people
from
injecting
any
default
routes
and
any
more
specifics
right
and
the
other
tool
we
have.
Is
that
the
way
redirect
works,
it's
actually
quite
constrained
or
the
validation
means
that,
if
I'm
a
host,
the
only
redirect
I
will
trust
is
someone
is
one
that
comes
from
a
source
address.
O
Just
responding
to
that,
the
router
that's
trusted
by
the
source
and
the
target
is
the
one
that
sends
the
redirect
and
the
this.
So
only
the
router
can
sort
of
prefix
that
will
be
trusted
by
everyone
and
any
other
know
that
tries
to
a
sort
of
prefix
without
having
gone
through.
The
router
isn't
going
to
be
listened
to.
So
the.
O
Yes,
that's
right,
but
the
na
message
is
only
going
to
be
confirming
what
the
router
told
the
source.
In
the
first
place,
the
redirect
tells
the
source
you
can
trust
that
this
guy
over
here
is
the
holder
of
the
prefix,
and
when
that
target
sends
back
in
na
the
source
will
accept
that,
because
the
router
was
the
one
that
informed
the
source
in
the
first
place
that
that
that
that
target
was
the
holder
of
the
the
RAL.
O
M
Nobody
is
it
only
triggered
because
there
was
a
redirect
situation
or
that's
that's
one
example
of
what
the
way
it
gets
triggered.
Yes,
well
not
one
example.
Security
is
the
worst
example
of
the
best.
Okay.
F
Lorenza
Kaluga
I
think
I've
seen
this
three
times.
Have
you
fixed
the
problem
where
the
Rooter
can't
deprecated
anything
anymore
in
the
sense
that
you
know
Rooter
says:
okay,
here's
a
whatever
64
on
link
and
then
you
parcel
off
for
whatever
it
is
that
you
want
to
parcel
off
the
96
104
and
you
give
it
to
some
other
node
and
how
does
the
main
route
or
renumber
that
link.
O
So
the
router
is
telling
the
source
that
a
target
is
a
holder
of
a
prefix.
And
how
do
I
talent
that
it
doesn't.
O
F
F
F
Routing
protocol
right,
you
need
something,
that's
up-to-date
and
then
can
be
updated
in
both
directions.
Right
now
you
have
a
unidirectional
update.
You
can
send
traffic
away
and
delegate
it
someone
else,
but
you
can
never
claw
it
back
and
and
the
security
implications
I
think
the
other
side
of
that
coin
I
think
it's
very
tightly
coupled
well.
The
router
is
your
security
trust
basis
for
the
lane.
I
get
it,
but
it
can't
take
anything
away.
Can
only
it
can
only
give
stuff
away
and
it
can't
take
it
back.
It.
O
F
This
merits
allegations
a
promise
right.
It
has
at
least
time
and
there's
there's
only
two
parties
involved.
So
if
you
do
PD
and
you're
the
Rooter
on
the
link
right,
if
you
get
a
packet,
then
you
send
it
back
to
the
person
that
you've
delegated
it
to
and
at
all
times
you're
in
control
of
that
forwarding.
If
that
least
times
out
or
if
you
decide
it's
no
longer
valid
or
whatever
you
just
don't
forward
the
packet
back,
but
here
you've
got
you're
telling
two
intermediaries
that
they
can
talk
to
each
other.
A
O
Scalability
issue,
though
no
not
necessarily
you're
not
going
to
have
you're
not
going
to
have
millions
of
correspondence
for
each
note.
You'll
only
have
a
few
correspondence
for
each
note
and
they'll
remember
that
they
got
a
neighbor
solicitation
from
the
cut.
O
F
F
F
F
You
have
a
security
problem,
no
okay,
so
or
maybe
in
your
security
environment.
This
is
acceptable,
but
in
general
for
VPNs
everything
is
hub-and-spoke
so
anyway,
maybe
maybe
we
just
need
an
applicability
statement.
So
I
think
this.
You
were
waving
we're
waving.
This
draft
waives
its
hands
over
like
some
pretty
fundamental
reliability
and
security
issues,
and
you
know
if
we
want
to
publish
this
it.
We
have
to
be
very
explicit
about.
You
know
how
it
scales,
what
the
security
properties
are
and
so
on.
M
O
M
W
F
O
F
O
C
So
I
had
a
also
a
couple
of
comments,
so
the
purpose
of
this
is
I
understand.
It
is
to
allow
the
nodes
to
talk
to
each
other
on
the
same
length,
but
most
of
the
things
you
list
up
here
at
the
top
like
Wi-Fi
does
not
allow
no
to
talk
to
each
other
directly
or
cellular.
It
all
goes
up
to
an
access
point
or
switch
or
something
at.
C
Ok,
but
so
I'm
basically
think
the
things
like
Wi-Fi
and
the
kind
of
things
you
talked
about
here
don't
support
the
kind
of
communication
that
you're
talking
about
I
I
can
believe
that
there
might
be
other
types
of
non
broadcast,
multiple
access
networks
that
will
do
this,
but
I
think
the
the
ones
you're
citing
here.
Don't
really
do
that
and
they
you
know
they
don't
want
to
do
that.
I
I.
O
C
O
Class
of
hosts
I
think
Class
C
host
type
C
hosts
are
borderline
the
same
consideration,
but
when
I'm
talking
about
a
type
D
host,
I'm
thinking
about
multi,
addressing
in
the
spirit
of
79
34,
which
would
say
that
you
get
a
prefix
only
for
addressing
within
yourself,
you
don't
have
any
networks
downstream
of
yourself.
In
that
case,
it's
very
host
like
right.
C
C
O
A
O
E
P
Think
I
may
not
have
time
to
complete
the
presentation.
I
try
to
just
try
to
give
the
high-level
summary
of
the
what
we
are
doing.
So
this
is
a
new
trap
which
is
informational,
and
it's
about
our
recent
research
for
the
transport
to
support,
also
higher
boundaries
and
also
low
latency,
and
so
the
our
motivation
is
that
the
current
network
is
it
just
the
best
on
the
best
effort,
IP
service
and
it
influence
transport
a
lot.
P
But
we
want
to
give
IP
level
service
with
kind
of
qsr
than
to
see
what
transport
can
behavior
and
the
basic
idea
is
that,
based
on
our
analysis,
that's
a
lot
of
background
analysis
in
the
draft.
I.
Think
if
you
are
interested,
you
can
cook
it
here
and
we
try
to
have
more
involvement
of
network
device
from
that
transporter
service
and
also
we
want
to
have
a
simpler
protocol,
because
we
know
that
eyes
will
be
kind
of
not
deployed.
P
So
we
have
this
kind
of
design
targets
and
the
some
talk
is
is
just
for
the
power
ability
and
some
tagless
is
for
the
network.
Neutrality
such
as
a
lot
last
winter
for
network
neutrality.
So
because
these
cover
a
lot
of
area,
I,
don't
want
good
details
and
next
page
please
so
conceptually
we
try
to
introduce
us
newer,
sub
layer
to
support
the
transport.
P
We
call
this
a
transport
control
and
what
we
want
for
this
transfer
control
is
that
firstly,
is
to
in
Venice
England
in
Venice
England
on
new
its
if
it
was
proposed
ten
years
ago
by
John
Harper
from
Cisco
that
time
it
could
come
out
TCP
quick
solution,
but
we
think
that's
not
good
enough
for
the
react
us
support
for
QA
earth
with
transport.
We
just
want
go
further,
and
this
layer
can
also
provide
the
congestion
control,
because,
right
now
the
condition
control
is
the
best
on
the
host.
P
Only
we
think
the
network
device
can
be
involved
a
lot,
because
the
network
device
know
what
exactly
happened
for
the
congestion
before
just
reuse,
the
packet
loss
or
delay
to
detect
or
gas.
The
status
of
congestion
for
network
and
next
is
for
the
possible,
where
M,
because
right
now
they
a
lot
of
information
for
the
IP
past
about
hop
number
latency
and
the
bandwidth
is
non
known
tool
and
user
or
application.
With
the
devising
moment.
P
We
can
get
either
information
of
this,
and
this
information
is
very
useful
for
the
application
to
decide
what
the,
how
much
amount
of
data
consent
quickly.
The
feasibility,
because
the
the
the
concept
was
there
but
before
the
hardware,
is
not
good
enough
to
support
this.
So
the
our
work
is
try
to
test
the
network
processor
to
see.
If
can
do
this,
especially
the
in
Venice
England
network
processor,
is
combine
the
post
advantage
of
as
you
can
and
CPU.
P
P
So
this
is
a
major
characteristics
of
the
control
plane
and
Deborah.
I
don't
go
to
get
her,
but
in
simple
is
that
for
control
plane
we
want
to
use
the
data
packet
to
carry
the
control
information.
Then
every
node
can
intercept
that
information
to
program
the
QoS.
Of
course
those
node
are
selectively
not
I
will
Evernote
has
to
do
that
and
they
for
data
plane.
It
not
only
provide
the
curia
support.
Also
it
can
keep
the
queue
s.
P
State
means
that
if
there's
no
third
packet
coming
to
refresh
or
use
that
secure
state
that
state
aware
be
raised
and
the
resource
will
be
released
so
by
this
idea,
then
our
control
protocol
will
be
very
simple,
which
means
that
we
don't
need
centralized
to
see
a
controller
card
to
control
this.
Then
all
control,
process
or
war
can
be
distributed
on
the
line
card
or
mu,
because
mu
is
not
like
the
control.
P
So
here
is
a
solution
for
ipv6
very
simple,
because
ip6
provide
very
powerful
extension
right
now.
We
are
using
true
extension
for
this.
Why
is
a
hop-by-hop
extension
which
for
the
programming
for
the
node-
and
the
next
thing
is
that
destination
extension
which
is
used
for
the
programming
state
reporter
sauce
and
I?
Think
for
this
community?
We
only
care
about
ipv6,
so
I,
don't
wanna
go
to
ipv4.
Ipv4
has
a
lot
of
problem,
so
next
page.
P
So
here
is
a
how
it
works
very
simple
that
there
every
data
packet
can
be
TCP,
sing
or
TCP
data.
When
the
sent
to
one
direction
it
can
carry
the
singling
information
which
was
inserted
by
application
or
system
is
by
host.
Then
those
information
will
be
intercepted
by
the
recorded
haba
haba,
aware,
ordered
it
been
intercepted
by
those
waters
and
the
program
hardware.
The
hardware
programming
state
will
be
returned
to
the
update
to
the
extension,
header
and
extension
header
will
accumulate.
All
states
of
programming
hop-by-hop
then
sent
to
the
destination.
P
Then
the
destination
will
convert
all
those
programming
states
to
test
destination.
Extension
header,
then,
that
information
is
sent
to
the
sauce
source
will
know
that
what
is
the
programming
state
then
connect
decision
accordingly,
for
example,
if
they
they
know,
the
bandwidth
is
not
enough.
They
can
either
lower
requirement
of
bandwidth
or
use
other
protocol
to
select
different
IP
paths,
because
right
now,
this
is
using
the
try
to
use
a
past
that
IP
for
folding
decided.
P
So
luckily,
in
our
real
system,
the
the
node
which
you
require
to
be
haba
haba
aware,
is
not
too
much
because
for
the
transport
point
will,
if
the
link
or
port
is
been
resisting,
not
enough,
no
matter
how
much
you
report,
the
pandavas
will
be
guaranteed
only
have
to
care
about
those
lawyers
which
likely
be
congested
or
aggregates
the
traffic.
Then
for
those
rotors
we
can
configure
to
be
the
hubba-hubba
aware.
Then
those
rotors
will
program
like
us
accordingly,
so
the
below
the
picture
is
that
for
the
real
Network.
P
Normally
we
have
a
cup
of
congestion
point
which
likely
to
be
programmed
for
Q
s
if
you
run
or
want
to
have
a
kind
of
guaranteed
service
for
follow.
So
next
page
the
most
concern.
The
problem
is
the
scalability
of
performance
in
our
experimental
week
with
to
test
this
very
slowly.
So
right
now
for
the
in
touch
with
the
normal
CPU
is
the
the
the
highest.
The
processing
power
is
about
200
gig.
So,
let's
assume
that's
a
a
processing.
P
Power
of
CPU
is
100
K,
then,
because
this
technology
is
not
used
for
the
application,
which
is
not
sensitive
to
the
bandwidth
shortage
or
larger
latency.
This
technology
is
only
used
for
the
application
which
we
require
a
lot
of
bandwidth
and
very
sensitive
to
the
packet
loss.
So
we
can
easily
assume
that
if
we
divide
the
resource
of
100
K
to
be
a
50%
for
new
session,
then
if
each
session
it's
the
hunger,
the
Mac,
then
we
only
need
to
support
500
session
first
mgu.
P
This
is
really
feasible
and
also
for
performance,
because
right
now
the
each
mq
intercept
the
single
message
and
the
program
cures
in
our
test
is
about
a
single-digit
millisecond,
less
than
sometimes
in
lesson.
1
millisecond.
But
let's
assume
it's
a
10
millisecond.
If
it's
a
32
hob,
it's
only
320
millisecond.
P
So
the
top
is
a
lot
for
the
application
which
we
require
out
high
bandwidth
and
ultra-low
latency,
because
right
now,
with
the
improvement
with
development
of
the
5
g
and
the
bi,
the
requires
a
content
provider
to
be
close
to
the
access
network
as
close
as
possible.
So
study
2
happens
a
lot.
So
basically
the
scalability
and
the
performance
is
kind
of
acceptable
from
our
inks
experiment
next
page.
So
because
for
this
chapter
you
covered
the
ipv6
and
also
transport.
P
So
we
have
another
presentation
in
the
Friday
for
detail
the
result
of
the
transfer,
the
congestion
control
and
also
it
has
all
the
areas
I
listed
in
the
draft
as
other
issues
yeah.
If
you
are
interested,
please
read
it
and
this
work
also
in
progress
in
the
Etsy
NGP
group.
So
there
we
will
have
a
much
more
detail.
It's
cutting
there
after
the
securing
it
will
have
a
lot
of
supporting
slice.
If
you
are
interested
just
read
it,
your
feedback
is
very
appreciated.
W
Yeah,
a
good
for
question,
one
was
already
answered
because
I
don't
sing,
it's
only
about
a
living.
Sorry,
it's
nothing
about
ipv6!
Here,
that's
about
transport
protocol,
but
you
answer
it
just
now
on
the
draft
you
talk
about
a
pv
for
in
six
month
is
kind
of
weird
yeah,
yeah
and
I
want
to
read
it
and
3/4
of
the
draft
is
about
QoS,
which
is
and
network
processor,
with
that,
don't
think
needs
to
be
there
in
a
six-man
draft.
W
It's
only
the
last
quarter,
which
explained
that
you
want
to
use
some
extension
headers,
which
is
fine,
so
I
would
recommend
to
remove
the
introduction,
which
is
longer
than
the
rest
and
the
last
point
you
need
to
specify
that
as
you're
using
central
header,
it
will
not
go
outside
of
an
administrative
domain.
Yeah.
P
Right
now
actually
look
in
my
trap,
because
this
is
a
big
area.
I
I
just
say
that
for
this
chapter
we're
only
focusing
a
single
domain,
but
in
tech
from
technology
point
of
view,
so
no
problem
to
expand
it,
of
course,
for
this
traffic
we
only
need
me
that
you
want
on
me.
Yes,
clothes
coming!
Okay!
Thank
you!
Thank
you!
Yes,
so
so
thank
you.
C
We're
at
a
time
so
thank
you
very
much
so
I
mean
the
discussions
we've
had
on.
This
is
I.
Don't
think
six
men
is
going
to
own
this
work.
I
think
it
belongs
more
in
something
like
transport.
There
may
be
some
packet
formats
for
us
to
look
at,
but
the
the
the
architecture
is
proposing.
I.
Think
is
sorry.
Oh
sorry,
I
was
we
were
conclusion.
Is
that
this
work
probably
is
not
going
to
be
owned
here.
It's
much
I
think
transport
is
a
better
place
for
it.