►
From YouTube: IETF99-6MAN-20170717-0930
Description
6MAN meeting session at IETF99
2017/07/17 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
A
B
C
B
D
C
C
B
And
Olli
will
do
document
status
right.
So
since
ITF
98,
we
have
published
three
new
documents.
Perhaps
the
most
important
ones
are
80
280
201,
which
is
the
yes
and
good
work
Bob
for
for
guiding
those
through
their
somewhat.
B
Dangerous
water
set
at
times
and
and
we
have
advanced
to
internet
standard,
also
in
place
for
4
4
3
&,
3,
5,
9
6.
So
that's
the
DNS
and
ICMP
options
and
we
have
parked
4291
base
as
we
could
get,
not
no
consensus
in
so
Suresh
I.
Don't
know!
We
have
one
more
slide
on
this.
If
you
want
to
talk
well,
you
can
talk
about
it.
Now
or
later
it
yeah
go.
Yeah.
B
Waiting
for
right
up,
we
have
the
max
are
a
draft.
That's
your
Suresh!
That's
ready
to
advance
right!
Thank
you,
and
we
have
three
active
working
group
documents
denote
requirements
on
the
agenda.
The
ORS
are,
a
refresh,
has
expired,
so
I
think
we
need
a
note
from
the
authors
there
if
they're
still
interested
in
progressing
that
draft
and
then
the
segment
routing
header
document,
which
is
not
on
the
agenda
this.
This
idea.
E
Krisshnan,
so
the
reason
I
send
this
back
to
the
working
group
right,
it's
like
I,
was
looking
at
all
the
stuff
that
happened
in
naive
last
call
and
I
didn't
see
any
easy
there.
Solutions
to
the
concerns
raised
so
there's
like
kind
of
it's
a
very
polarized
community
like
if
I
put
it
mildly
and
there's
not
like
any
words
waiting.
E
Don't
want
to
see
this
back
until,
like
those
things
results,
I
really
would
like
the
working
group
to
try
to
solve
this.
Take
the
time
and
solve
something
here
and
I,
hopefully
had
don't
have
to
call
consensus,
but
if
I
have
to
I
will
write.
I
saw
so
I'm
kind
of
keeping
off
from
the
active
discussion
on
this.
But
I
really
would
hope
that
the
working
group
can
converge
on
something.
B
B
B
B
B
So
we
have
currently
still
in
draft
standard
is
the
addressing
architecture,
privacy,
extensions,
neighbor,
discovery
and
slack,
which
is
probably
quite
a
big
piece
of
work,
the
v6
over
P
P
and
in
the
original
plan
we
made.
We
also
talked
about
advancing
in
the
v6,
the
auto
v6
or
a
few
documents
in
probably
in
particular,
ipv6
or
Ethernet.
B
Any
views
in
the
room
of
where
we
want
to
go
with
this
work.
Do
we
want
to
continue?
Have
we
been
so
scarred
by
the
four
documents
that
we've
done,
that
we
can't
wanna
wait
a
few
years
and
see
if
we'll
recover,
because
we
have
at
least
in
my
experience
we
have
in
opening
old
wounds,
might
might
not
be
the
most
pleasant
of
activities,
but
at
least
you
know,
at
least
in
theory.
We
should
be
doing
something
with
these
draft
documents.
B
F
G
F
F
I'd
like
to
make
a
request
of
the
chairs,
can
we
add
this
slide
as
the
last
item
today
since
we're
going
to
be
discussing
some
of
these?
It
may
be
that
we
decide
just
to
abandon
or
or
give
up
on
some
of
these
things
and
then
come
back
and
decide
whether
if
we
decide
hey,
you
know
we're
not
gonna
make
any
changes
to
addressing
architecture.
Maybe
we
don't
need
to
add
that
as
a
milestone
right
so
yeah
look.
Can
we
ask
these
questions
in
an
hour
and
a
half
yeah.
B
G
B
C
If
this
works
so
yes
I've
pretty
much
talked
about
this.
Since
the
document
was
parked
I
submitted
to
based
on
the
discussion
submitted
to
new
drafts,
eight
and
nine
and
so
I'm
going
to
talk
about
the
changes
and
well,
let
me
just
do
it
I
press
the
right
button,
so
these
are
the
I
think
the
smaller
changes
removed
the
instructions
Diana
about
the
port
number
assignment.
You
know,
I
Anna
fixed
the
the
problem
in
March
and
I.
C
Read
it
like
I
did
in
the
other
two
documents:
the
changes
since
since
4291
to
have
both
the
you
know,
draft
by
draft
changes
which
will
get
removed
by
the
RFC
editor,
but
and
then
then
a
single
section,
which
is
the
actual
summary
of
the
changes,
not
not
the
because
several
of
the
things
where
went
both
ways.
If
you
look
at
the
per
graph
and
then
I
also
removed
the
short
paragraph
about
manual
configuration
that
was
added
in
Oh
8,
because
I
based
on
some
comments,
I,
don't
think
it
actually
had
any
value.
So.
C
C
You
know
whether
it's
on
link
and
and
and
it
used
for
creating
addresses.
So
if
there
are
comments
on
this
change
well,
you
know
where
the
mic
is
and
then
the
other
preach
Ange,
which
I
think
was
was
suggested,
which
I
think
makes
sense
is
to
talk
about
how
how
prefixes
use
this
is
intended
to
resolve
the
questions
about
on
Lincoln,
not
on
Linc
and
so
forth,
without
getting
into
infinity.
G
C
So
this
is
the
text.
I
came
up
with
for
the
based
on
the
discussion
about
slash
64
I've,
seen,
there's
some
support
for
on
the
list.
There's
some
other
text.
That's
been
proposed.
I
think
this.
This
is
the
you
know
the
big
tussle
we're
having
is
about
this
text.
I
think
this
text
does
talk,
you
know
say
talk
about
interface,
identifiers
are
64
bits
except
enlists,
the
exceptions
and
so
I
think
this
meets
a
lot
of
the
require
a
lot
of
the
things
that
have
caused
this
discussion.
H
There's
no
actual
need
it's
just
back
to
the
history
of
TLA
and
LA,
and
trying
to
tell
operators
who
are
the
enemy
of
ipv6.
What
to
do,
and
for
those
who
don't
know
me,
you
might
remember.
You
should
know
that
you
know
our
network
was
the
first
to
deploy
v6
commercially
in
97
right.
It's
not
that
I'm,
a
v6
hater!
That's
how
my
v6
lover
and
this
stuff
makes
it
painful.
H
Okay
and
slack
is
not
restricted
to
64
bits.
I
might
do
60
bits,
I
might
do
72
bits
and
it
works.
The
thing
that
you
don't
want
to
do
with
slack
is:
have
it
so
small
that
privacy
addresses
don't
have
enough
space
for
entropy
and
the
simple
little
stupid,
classless
v6
document
points
that
out.
So
this
is
a
little
bit
of
an
inverse
and
I.
Think
the
classless
v6
says
it
a
little
more
clearly.
C
F
Lee
Howard
I
think
that
you
are
accurately
describing
the
way
the
Internet
is
running.
Now
we
have
running
code
on
this
and
I'm,
not
clear
that
we
have
consensus
other
than
this
I
wonder
if
the
if
the
crux
of
the
with
against
this
language
I
want
the
crux
of
the
the
argument
is
over
the
word
manually
and
specially
would
be
a
different,
a
better
way
to
describe
it
that
if
you
have
other
special
configurations,
but
the
default
configuration
64
bit
but
I'm
happy
with
the
sex
with
whoopsie
before.
I
Kaliki,
you
can
find
me
only
attendees
list,
just
to
probably
other
side
of
that
tussle
I.
Think
as
a
you
know,
we
build
host
operating
systems
and
I
I
find
that
you
know
we.
This
is
very
close
to
what
we
have
always
had
written
in
the
standards
and
very
close
to
what
we've
had
for
twenty
years
and
I.
Think
really.
The
value
of
this
number,
this
64-bit
number
is,
is
reserved
really
it's
reserved
for
future
use.
I
It's
reserved
for-
and
you
know,
20
years
from
now,
we'll
figure
out
something
new
and
this
stuff
has
got
to
be
empowering
the
internet
for
three
four
or
five
decades
for
now,
and
we
don't
have
a
pressing
need
to
relax
this
restriction.
It's
not
clear
to
me
that
we
have
in
need
that
we
have
some
use
cases
that
would
benefit
from
it
immediately.
I
I,
just
don't
see
them
and
so
I,
don't
you
know,
I,
don't
see
a
big
need
for
this
I
would
in
fact,
I
would
even
remove
the
by
exceptions
to
financed
an
abstract
documents.
We
don't
even
need
to
say
that,
because,
by
definition,
a
standards
track
document
can
update
this
document
and
I.
In
fact,
I
would
prefer
to
see
that
text
gone.
J
Snider's
NTT
communications.
What
I
would
like
to
see
in
the
total
body
of
work
is
that
in
no
way
hardware
vendors
are
allowed
to
take
shortcuts
and,
for
instance,
a
we
only
supports
964
because
of
hardware
limitations
or
reasons
I
do
see
value
in
many
cases
to
use
/
64.
Let's
call
it
the
majority
of
cases
I
just
would
really
hate
it
to
happen
that
some
vendor
at
some
point
says
this
prefix
length
will
not
work
with
our
hardware
and
that's
because
ITF
specified
it.
This
way,
we've
seen
this
in
the
past,
it
causes
pain.
J
Well,
because
it
focuses
on
slash
64
and
it
then
as
an
example,
this
127,
what
happens
to
the
things
in
between
so
one
possible
solution,
would
be
to
remove
this
from
the
documents.
So
there
is
no
/
64
of
references
in
this
particular
document,
but
each
protocol
that
requires
64
or
requires
something
else
specifies
it
themselves.
C
Well,
I
mean
that
there
is
other
text
in
the
document
that
does
say
that,
for
example,
routing
should
work
with
any
prefix
length.
That's
routing,
right,
pardon
and
I
mean
it's
not
on
the
slide,
but
it's
it's
in
well,
it's
been
in
I.
Think
I
was
7,
8
&
9
that
there
is
that
you
know
so
this.
This
text
is
now
in
the
inner
about
in
in
the
section
about
interface
IDs,
which
is
I,
think
where
it
belongs,
but
in
the
section
of
unicast
addresses
it
there
is,
we
could
pull
it
up.
C
There
is
text
that
already
says
that
you
know
ipv6
Radames
should
work
with
any
prefix
length.
Then
what
is
the
value
of
this?
Well,
because
it's
for
some
of
the
reasons
I
think
other
people
said
it's
about
interface
IDs,
but
you
raise
the
issue
of
whether
you
wanted
to
make
sure
that
and
I
agree
with
you
that
we
want
the
hardware
to
work
with
any
prefix
alone,
and
so
but
I
think
that
would
be
driven
by
the
text
in
the
unicast
section.
Not
not
this.
Perhaps
it
would
be
simpler
if
them.
This
paragraph
is
just.
K
You
Geordi
palette,
I,
basically
agree
with
what
Lorenzo
said
and
in
addition
to
that,
I
think
is
perfectly
normal
in
many
other
standards
to
have
exceptions
so
I
don't
think
there
is
anything
wrong
having
an
exception
here.
Furthermore,
I
I
actually
think
that
FC
61
64
is
is
broken,
I
mean
I.
I
will
really
advocate
it's
it's
a
different
topic,
but
I
will
really
advocate
for
his
last
64,
always
okay.
Thank
you.
Okay,.
L
As
an
operator,
I
do
have
I
do
see
value
in
restricted
interface.
I
did
allege
64,
because
I
see
problems
which
could
be
created.
If
you
start
allowing
to
have
interfaces
idea
of
variable
Alex
and
again
as
I
+1
tall.
What
Lorenzo
said.
I
cannot
see
what
problem
we
would
solve
by
allowing
variable
X
right,
so
I
do
believe.
We
need
to
keep
it
fresh
64.
L
Unless
yeah,
there
are
clear
defined
exceptions
like
point-to-point
links,
yeah,
because
I
think
we
all
pay
in
a
door
for
problem
and
future
I
have
spent
too
much
time
when
my
life
discussion.
Should
these
subnets
be
slash,
27/28
or
27,
or
slash,
24
and
so
on.
Right,
I
think
it
be
it's.
It
was
in
progress,
make
it
in
his
idea.
Always
64
should
keep
it
like
that.
Thank.
M
I
think
that
any
specific
value
Mari,
whether
that's
64
or
anything
else,
I,
don't
think
that
would
belong
to
an
architecture
document
I
mean
that
doesn't
mean
that
I'm
in
favor
of
one
value
or
another,
but
I,
think
an
architectural
document
that
wouldn't
be
the
place
for
setting
a
specific
value.
Now,
with
respect
to
the
specific
value,
I
personally
think,
besides
that,
it's
like
sigh
comment:
I,
think
that
when
you
specified
values
such
as
these,
that
allows
vendors
to
assume
that
that
value
will
always
be
the
case.
N
Thank
you,
hi
James
with
yet
and
nest
labs
I'd
like
to
follow
up
to
something
where
Enzo
said
about
specifically
this
phrase
about
or
when
defined
by
a
standard
track
document
I
believe
I'm,
the
guy
that
proposed
that
phrase
and
I
believe
that
my
motivation
for
proposing
it
was
in
the
hopes
that
it
would
help
ameliorate,
a
controversy
and
the
controversy
by
establishing
a
compromise
that
people
could
accept,
and
then
we
could
move
forward.
I,
don't
believe
that
compromise
has
been
honored
and
I
agree
with
Lorenzo.
N
D
O
P
I
Our
integrity,
I
think
I,
really
yeah
I,
really
don't
like
that
text,
sections
to
find
an
standards
track
documents,
there's
lots
of
those
documents
and
I
think
six-man
has
a
in
the
Charter.
It
has
a
it
has
a
special
review,
responsibility
and
and
I
think
power
that
you
know
it
may
request
that
any
specification
that
affects
the
internet
standards
needs
to
review
in
this
working
group.
Q
Thank
you
totally
sacred.
Yes,
so
in
enema
we
do
have
a
solution
where
we're
you
know
automatically
creating
you
know.
Tens
of
thousands
of
internal
subnets
in
devices
which
you
know
for
efficiency
of
routing
would
have
to
a
fairly
long
mask
so
that
we
can
scale
it
right
now.
It's
between
you
know,
96
and
127,
and
listening
to
this
conversation
here,
I
think
that
it's
perfectly
valid
to
you
know
have
reviews
for
any
of
these
things
and
I
I'm.
Also,
you
know
having
this
fear
of
unknown.
Q
You
know
things
that
come
in
the
future
that
were
not
aware
of
so
anything
that
helps
in
the
text
to
make
sure
that
you
know
the
people
in
the
know
who
understand
all
the
ITF
processes.
No
must
happen
like
you
can
write
a
standard
that
overrides
this
or
you
know.
If
you
establish
something
that
you
know,
you
think
is
a
good
practice
should
be
documented
and
best
practice.
I,
don't
think
it's
a
bad
thing
to
write
that
down.
Even
if
it's
replication
of
some
you
know
crazy
documents
that
exist,
but
an
operator
would
read
this.
Q
H
I
That's
actually
a
good
point
right.
Do
we
one
do
we
want
like
would
would
we
want
a
document
such
as
the
classless
ipv6,
a
draft
to
be
able
to
change
this
text
without
formally
updating
4291?
Would
we
I,
wouldn't
write?
I
mean
kiss
is
in
direct
conflict
right
and
so
specifically,
I
think
we
should
say
unless
this
document
is
updated,.
H
R
C
R
Closer
to
the
mic,
if
I
hear,
if
I
hear
the
argument
in
both
side,
I
mean
the
company
did
the
one
hakama,
that's
very
strong
on
the
hey,
we
are
to
be
able
to
do
viability
and
cetera
is
assuming
that
your
ISP
or
your
provider
gives
to
the
consumer
networker
slash
64,
which
we
know
it
will
because
there's
so
much
legacy
that
if
you
give
something
else,
it's
gonna
be
constrained
by
your
support
line.
Will
explode
so
you're
not
going
to
do
that.
R
But
the
point
is
that
suppose
it
exceed
gives
us
X
64,
and
you
want
to
have
a
complex
home
network.
What
do
you
do
now?
You
could
do
many
thing.
One
thing
you
might
do,
which
is
kind
of
the
assumption
in
the
class
test
draft,
is
that
you
will
have
multiple
segments,
each
of
which
are
their
own
prefix,
and
you
are
configured
that's
one
assumption,
but
that's
by
no
mean
the
only
possibility
or
necessarily
the
best
possibility.
What
I
don't
see
is
an
effort
to
get
a
consensus
architecture
on
this
large
customer
networks.
R
If
we
add
a
consensus
fact
that
that
says,
okay,
we
have
this
Prime
of
large
consumer
networks.
We
have
a
way
that
they
should
be
meeting
some
requirements,
that
I
don't
partically
know.
Then
we
might
get
a
consensus
on
the
way
to
do
that,
and
the
changes
in
addressing
would
eventually
follow
that
consensus.
If
there
is
one
in
the
absence
of
that
I
doubt
that
we
can
ever
converge
so
to.
C
R
G
Client
for
the
I
believe
on
the
mailing
list.
There
was
a
call
for
people
who
want
to
eliminate
a
bunch
of
this
text
to
sort
of
provide
a
problem
statement
as
to
what's
actually
what
actually
is
the
difficulty
with
vendors
and
relationship
to
IDs
I
have
not
seen
one
but
perhaps
I've,
not
read
every
email
on
the
list
or
have
not
been
participant
to
every
discussion.
So
perhaps
a
problem
statement
about
the
problems
that
this
causes
might
help
clarify
the
direction
we
need
to
go.
H
Bush
IJ
I
have
sympathy
with
Christians
problem
and
there
are
other
areas
in
the
ITF
also.
H
I
have
sympathy
with
the
Christians
expression
of
the
problem,
but
it's
as
I
is
actually
being
looked
at
in
other
areas
like
home.
That
the
problem
to
me
is
that
what
will
happen
is
if
I
give
them
a
64
instead
of,
for
instance,
of
60
with
PD
is
what
they're
going
to
do
isn't
submit.
C
Yeah
I
mean
in
some
ways
my
take
on
this.
You
know
if
I
had
to
go
back
I,
you
know
had
we
done
it
where
interface
IDs
the
length
yeah
if
they
were
48
bits
long
and
you
have
say
bits
before
that
or
it
subnets
I
suspect.
You
know
that
sort
of
makes
sense
to
me,
but
I
think
I
I'm,
pretty
convinced
that
we
would
be
having
the
same
discussion
regardless
of
what
that
boundary
was
bingo.
H
H
I
Lorenza
could
Evi
I
would
I
think
I
agree
with
you
Bob.
You
know
no
matter
which
number
we
pick.
There's
gonna
be
an
argument
and
I
think
you
know.
We've
got
the
hosts
the
hosts
on
one
side
that
would
like
to
maintain
innovation
and
would
like
to
be
able
to
do
to
avoid
doing
that.
And
then
you
got
operations
on
the
other
side
who
say
well.
They
have
a
need
to
assign
whatever
lengths
is
appropriate
for
them
for
the
HomeNet
foot
for
the
extending
network.
I
At
the
edges,
discussion
like
we
have
guidance
on
that
in
home
that
it
says
don't
assign
just
a
64,
and
you
know
if
people
ignore
that,
then
you
know
whatever
number
we
pick.
It's
gonna
be
the
same.
We
we
say
well,
okay,
now
we
move
the
boundary
to
80.
That's
fine!
Now
my
host
pool
accept
an
80.
Here's
an
ad
have
a
nice
day.
So
what
do
I
do
with
that
right?.
S
I
So
I
think
you
know
that
that's
you
know,
I,
don't
think
we
should
even
just
go
there
right.
We
haven't
you
know.
If
we
don't
have
a
boundary,
then
we'll
basically
lapse
back
into
IP
before
where
the
boundary
is
128.
I.
Think
there's
just
no
no
point
in
that
really
so
we
have.
We
have
guidance
on
that
case.
It's
not
a
problem
statement.
We
have
ITF
consensus
on
that.
I
F
T
All
right
tell
me,
sir:
are
he
Marvel
I
work
for
a
chip
vendor
so
as
an
implementer?
First
of
all,
it's
important
for
me
to
know
whether
the
IIT
is
64
bits
long
or
not,
but
it's
also
important
to
know
how
to
optimize
the
implementation.
That
is
even
if
the
implementation
supports
arbitrary
length,
I
IDs
still,
you
need
to
know
whether
the
system
works
optimally
for
64
bits
or
for
arbitrary
links.
T
C
I
Hi
there
John
was
asking
so
honestly
I've
kind
of
been
ignoring
this
thread
on
the
list,
largely
for
a
variety
of
reasons
which
we
can
talk
about
later.
But
but
the
thing
that
is,
you
know,
the
the
conversation
might
got
me
thinking
about
is
is
that
you
know
you
need
to
be
very
careful
about
the
water
that
you
tread
in
right
now,
right.
I
Making
the
prefix
making
the
interface
are
making
the
interface
identifier
smaller,
for
example,
would
have
a
pretty
pretty
significant
side
effects
right
on
the
flip
side.
You
know
as
much
as
you
know.
We've
talked
about
this
for
years
here.
Right,
oh
hey,
you
know,
give
everybody
a
56
or
what
everybody
fault.
Many
other
operators
in
the
room
will
tell
you
that
there
be
many
case
where
that
happens,
where
it
breaks
the
right,
I
still
get
device.
I
This
show
up
like
three
months
ago
that
advertise
a
Pio
as
it
with
a
fifty
six
value
in
it
right,
not
okay,
right
can't.
You
know
it
doesn't
work
right,
I
mean
and
you
Bob
yeah,
as
one
of
my
customers
have
a
pretty
good
I.
Think
customer
experience,
because
we've
taken
a
very
conservative
approach
to
make
sure
that
we
don't
screw
you
right
right
and
that's
how
important.
I
That
well
and
and
I
need
you
to
I.
Need
you
to
remember
that
dude
right
I
need
you
remember
that
when
we're
talking
about
stuff
like
this,
because
you
know,
we've
taken
great
care
to
do
that,
to
make
sure
that
you
don't
have
a
shooting
experience
right
and
I
think
the
changes
that
we
make
here.
We
have
to
be
very
mindful
about
this
right
because
they
will
have
side
effects.
People
will
read
all
these
things
out
of
context,
and
next
thing
you
know:
you're
not
gonna,
have
such
a
great
experience.
Alright.
So
you
know
peace.
Q
Tone
sacred,
so
it's
closer
to
the
mic,
please
so
I
think
this
discussion
provides
a
lot
of
good
inside
of
you
know
the
pros
and
cons,
and
you
know
I,
don't
see
any
of
that
being
written
up
and
I,
don't
think.
As
an
ox
group
you
have
the
you
know,
excuse
of
oh
it's
just
the
standard,
and
we
don't
want
to
explain
why.
So
it
would
be
really
good
if
you
know
more
of
this,
these
things
of
justifying,
where
we
stand
in
the
text.
C
The
I
think
the
most
constructive
thing
I
heard
in
this
discussion
is,
is
to
try
to
write
down
not
for
this,
but
in
a
separate
document.
What
essentially
we're
trying
to
accomplish,
and
because
you
can't
everything
is
about
reading
between
this
discussion-
is
about
reading
between
the
lines,
and
you
know
four
sentences,
so
I
think
if
we
were
to
write
a
document
like
that,
and
if
we
could
talk
about
it
in
more
depth
and
get
consensus
on
that,
then
we
could
probably
figure
out
what
to
put
in
this
document.
C
G
C
V
I
Lorenzo
Cleary
yeah,
please
put
a
problem
statement
and
that
Lorenzo
clearly,
please
put
a
problem
statement
of
that
in
that
draft
in
the
form
of
stuff
that
needs
to
be
solved.
Saying
we
had
a
problem
in
ipv4
in
the
90s
and
cider
is
obviously
the
best
solution
for
everything,
and
so
we
should
do.
It
is
not
a
problem
statement
and
it
is
a
proposal
for
a
solution,
but
it
is
not
a
problem
statement
specifically.
I
The
question
that
I
have
never
seen
answered
to
any
degree
of
completeness
is:
what
can
we
do
with
smaller
or
rather
longer
prefixes
that
we
can't
do
the
64
bit
prefix?
The
answer
if
I've
heard
so
far
are
defend
against
nd
cache
attacks,
but
that's
trivial.
You
just
use
you
just
don't
forward
those
packets
and
number
two
I've
heard
extending
the
network
at
the
edge
and
I've
heard
several
comments
here
to
the
effect
that
that
won't
work,
because
it'll
just
move
the
boundary.
So
yes,
I
think
we.
I
S
Barbara
start
I
keep
hearing
that
if
we
allow
for
longer
prefixes
operators
will
you
know
hand
out
the
longer
and
longer
and
longer
prefixes?
Is
there
any
evidence
that
operators
will
do
this
I
mean
because
this
is
pure
speculation
as
far
as
I'm
concerned?
That
has
no
evidence.
I
J
J
Sorry,
there
are
companies
that
do
hold
the
interests
of
their
customers
at
heart
and
adhere
to
good
suggestions
like
give
them
ample
space,
and
there
are
the
ones
that
don't
if
I
recall,
ipv4
history
in
the
Netherlands
when
we
started
out
with
DSL
and
dial-in
and
everybody
would
get
tons
of
ipv4
space
until
those
poles
started
running
dry
and
the
reason
we
nowadays
have.
Basically
one
IP
address
per
connection
is
I.
J
Think
originally
it
started
with
scarcity
which
doesn't
apply
in
ipv6,
so
I'm
actually
quite
optimistic
that
companies
may
assign
ample
of
IP
space,
provided
that
there
is
clear
documentation
that
suggests
to
assign
them
ample
space
and
I.
Think
there
is
a
ton
of
that
documentation,
so
I'm,
not
that
worried
that
we'll
end
up
with
just
one
address
per
connection.
R
Christian
you
oedema
and
I
think
that
we
really
need
the
prime
statement
and
I
do
not
think
that
the
existing
classless
draft
is
the
problem
statement
they're
the
things
that
it
does
not
cover
our
things,
for
example
like
the
dynamics
of
min
the
game
theory
of
address
allocation,
and
what
can
happen
and
I
am
NOT,
saying
that,
because
I'm
entirely
sure
that
it
will
happen
in
bed
with
it,
it
could
I
mean
we
have
seen
you
use
it.
Things
like
that.
We
also
have
to
have.
R
On
the
other
side
the
existence
of
legacy,
which
is
part
of
the
problem,
I
mean
there's
a
bunch
of
system
ax,
a
Windows
7,
for
example,
a
Louisville
shuttle
mark.
There
are
bunch
of
us
deployed
systems
an
example
being
Windows
7
that
are
not
going
to
be
updated.
I
mean
that
part
of
the
code
in
Windows
7
is
not
going
to
be
updated
for
us
or
10
years
at
which
point
machine
will
be
obsolete.
R
R
If
you,
if
you
under
64
bit
yeah
64,
not
another,
it
depends
on
a
bunch
of
legacy
equipment
legacy,
routers
things
like
that.
Okay,
so
there
will
be
customer
issues.
Definitely
so,
given
that
I
really
believe
that
a
the
document
that
we
have
the
classes
document
is
a
solution
document
not
so
much
a
problem
statement
and
that
B
we
do
need
to
prime
statement.
G
L
Genuine
cover
I,
just
like
to
point
out
that
there
is
a
documentation
which
you
commands,
subnet
sized,
which
should
be
allow
a
to
site
and
we
still
see
and
it's
being
violated
so
I
do
not
seem
just
the
commune
Tiant
and
tellin
decorators
were
to
do
helps
right.
So
we
do
see
evidence
of
operators
doing
something
which
is
not
recommended.
That's
why
I
came.
L
Okay,
I
wanted
to
say
that
we
do
see
is
that,
despite
having
documentation
and
recommendation
for
prefix
lengths,
which
should
be
handed
out
to
customer
separators,
do
something
not
exactly
recommended
so
I
am
and
I'm
on
the
side
of
this
discussion.
Who
believes
that,
if
you
allow
them
to
make
it
shorter,
I
mean
they
give
customers
less
addresses
they
will
as
soon
as
we
allow
this.
B
Hopefully
we're
not
going
to
collect
parking
tickets
for
every
day,
but
I'm
not
quite
sure
what
the
path
forward
here
is
going
to
be
time,
heals
all
wounds,
perhaps,
but
let's
see
if
we
can
develop
some
more
workaround
problem
statements
more.
You
know
common
understanding
of
where
we
want
to
go
with
this
and
what
problems
we
we
want
to
solve.
B
Perhaps
we
should
encourage
more
work
on
extending
the
what
I
guess,
what
we
call
permission:
less
extension
on
the
edge
of
the
network
if
we
can
come
up
with
better
technologies
there,
but
this
is
just
going
to
be
an
ongoing
itch
to
scratch.
I
believe
I,
don't
know
Suresh.
If
you
want
to
have
the
last
comments
on
this.
E
Don't
know,
maybe
like
something
like
that
would
be
good,
because
we
are
all
at
the
idea,
but
we
all
have
like
a
lot
of
things
to
do,
and
it's
very
hard
to
find
time
to
do
just
this
one
thing,
so
maybe
something
a
bit
more
focused
would
help,
because
getting
all
the
people
together
and
talk
about
just
this
thing
might
be
helpful
because
I
don't
think
you
spent
like
a
lot
of
time,
understanding
each
other.
Like
that's
my
view,
thank.
D
I
I
Iii
there
are
problems
that
we
have
that
we
don't
know
how
to
solve
like
extending
the
network.
How
like
what
do
I
do
was
with
a
VM
inside
a
VM
inside
a
VM
like
one
thing
that
we
facing
with
the
with
the
Android
emulator
conformance
tests.
Is
that
you're
not
allowed
to
do
not
inside
the
device,
and
we
don't
know
how
to
assign
an
IP
address
from
a
64
inside
the
device.
The
only
thing
that
they
so
we
do
have
issues
there
and
we
need
api's
for
that.
I
I,
think
and-
and
so
we
do
have
work
here
ahead
of
us
I
think
wordsmithing
four
to
nine
one
is
is,
is
something
that
generated
a
lot
of
heat
but
I
think
in
reality
that
the
changes
are
extremely
minor
and
and
it
was
pumping
and
they
we
were
punting
on
those
hard
problems
completely.
We
just
said:
well,
we
do.
B
I
I
To
it,
so
what
I'm
suggesting
is,
let's
think
about
what
to
do
with
four
to
nine
one
and
I
see
two
options
to
like,
withdraw
it
or
to
say:
well:
okay,
we're
gonna,
they
I
think
if
we
remove
the.
If
we
remove
the
text
saying
you
know
by
exceptions,
you
know
if
we
remove
the
text
saying
but
exceptions
defined
in
standards,
tactic,
I,
think
we
might
get
consensus
on
that
and
then
move
forward.
I
I
think
if
we
don't,
let's
just
toss
it
because
you
know
fixing
the
problems
in
it's
gonna
require
way
more
than
what's
missing
that
paragraph
in
1491,
so
I
would
think
you
know
we
keep
having.
We
have
had.
You
know
all
over
the
past
few
weeks,
several
attempts
to
keep
doing
more
wordsmithing,
and
maybe
we
should
just
cut
that
cord
and
say:
look,
you
know
we're
never
gonna
go
we're.
Never
gonna
get
that
white
border
missing
these
five
lines.
I
B
So
the
document
is
parked,
and
perhaps
you
shouldn't
have
been
on
the
agenda
today,
but
just
judging
from
the
mailing
list
discussion,
it
seemed
to
be
at
least
worth
having
this
discussion
that
we
have
had
run
through,
but
it
is
a
part
document
which
means
you
know
it
will
sit
there
until
we
develop.
You
know
common
understanding
of
where
we
want
to
get
go,
and
then
we
had
two
more
barriers:
there's
lots
of
people
that
have
voiced
their
opinions
on
a
mailing
list
that
it's
not
in
this
room.
B
O
Okay,
so
on
this
is
a
working
group
document.
This
is
ipv6
node
requirements.
This
is
just
we've
made
an
update
since
the
last
meeting.
We
expect
we're
going
to
put
another
one
out
this
week
on
based
on
comments.
So
if
you
have
any
comments,
please
feel
free
to
put
them
on
the
list
or
come
to
the
mic
today.
Just
a
quick
reminder:
this
is
the
this
will
be.
The
third
iteration
of
this
document
we're
working
to
sync
with
the
router
document.
That's
going
on
in
v6,
hops
changes
from
this
time.
O
We
we
added
MLD
v2.
We
took
out
all
the
texts
about
v1.
The
older
version
of
this
said:
hey
v1
was
still
a
thing.
Most
implementations
at
a2
v2
we
added
80
106,
is
a
must
for
clients,
the
mobility
text
we
took
it
out.
Some
people
suggested
we
should
just
leave
it
in.
So
we
put
it
back
in
we
added
DHCP
in
a
man,
Dimity
profiles,
blue
RFC,
we
left
1981
alone
and
we
didn't
touch
DHCP
PD
for
host.
We
left
that,
if
not
on
no
text
in
it,
those
are
the
updates.
O
We
got
for
my
ATF
98
things.
We've
added,
we
reworked
it
a
little
bit.
We
added
some
text
about
constrained
devices
and
they
should
go
read
some
other
text
and
not
just
implement.
Everything
here
is
really
our
recommendation.
We
added
text
for
yang
and
net
comp.
The
original
draft
had
just
SNMP.
We
thought
that
was
a
little
outdated,
so
we
basically
said:
if
you're
going
to
do
Netcom,
do
these
yang
models.
We
added
some
mdns
text,
we
want
a
t28
and
then
we
added
ECN.
O
So
these
are
our
open
issues
that
people
might
want
to
get
up
and
talk
about
this
one.
Some
people
have
suggested
that
we
put
text
in,
in
particular
around
the
issue
of
ipv6
extension
headers.
We
can
do
that.
We
just
need
some
texts
and
people
have
suggested
they'd
offer
text.
We
haven't
seen
anything
so
right
now,
there's
not
anything
special
without
extension,
headers
other
than
what's
in
the
current,
updated
RFC's.
O
O
O
Alright,
this
is
an
interesting
one.
So
for
the
ready
logo,
testing
we've
always
required
that
host
support
redirects.
The
old
version
of
this
draft
said
host
should
redirect
I
would
suggesting
we
update
it
to
what
basically
every
host
does
support
redirects.
Obviously,
a
lot
of
hosts
allow
you
to
turn
off
the
processing
of
them.
That's
not!
What's
here,
it's
just
hey!
When
you
get
a
redirect,
you
should
understand
it
and
be
redirected.
I
know
that
there
are
other
people
who
use
this.
O
My
preference
would
be
to
upgrade
it
to
a
must,
but
I
think
security
makes
people
nervous
here
all
right.
Jumbo
grams,
it
Brian
carpenter
emailed
about
this
and
said
it's
not
hurting
anyone.
We
should
just
leave
it
in
I.
Don't
have
strong
feelings
about
this
I
I'm
a
little
nervous
that
people
think
that
they're
deployed
when
they
show
up
in
a
document
like
this
I'm
not
aware
of
a
whole
lot
of
usage
of
this
text,
but
it
isn't
Brian's
correct.
It
doesn't
hurt
anybody,
but
I,
don't
know
of
anybody
who
every
implements
it.
O
D
V
W
D
X
Think
I,
regulated,
Julie,
Glee
I
think
the
observable
phenomenon
is
if
they
were
actually
implemented
and
used,
they
would
be
harmful
right
because
serialization
is
still
a
thing
and
if
you
are
sitting
in
in
line
behind
a
you
know,
a
very
large
packet
you
have.
You
have
induced
latency
there
of
course
link
layers
where
this
is
appropriate.
Right.
G
G
N
I'm,
a
co-author
on
Fred
templates
draft
talks
about
route
information
options
and
extending
the
way
those
might
be
used
and
I
noticed
that
64
34
and
this
draft
don't
really
seem
to
say
as
much
as
I.
Think.
I
would
like
it
to
say
about
RFC,
41.9
t1,
the
default
router
preferences
and
more
specific
routes
RFC.
It
says
it
should
support
RFC,
41.9
t1
yeah,
but
it
doesn't
say
anything
about
what
type
of
host
it
should
be
in
the
context
of
that
RFC
type:
a
B
and
C
yeah.
N
N
O
I've
had
this
problem
in
other
profile
places
too
I,
don't
know
what
the
right
answer
it
never
gotten
consensus
from
a
group
of
people
and
what
type
of
they'd
like
I
mean.
Clearly,
if
you
look
at
the
three
choices,
be
looks
really
nice
but
cease
work
I
the
problems
you're
gonna
run
into
here
right.
His
nodes
are
different
on
every
network
and
the
reason
that
they
did
write
the
3dep
types
down.
We
can
try
I'd
have
to
go
back
and
reread
it
and
refresh
my
memory
on
the
exact
differences
between
the
B
and
C.
O
N
O
N
G
Eric
Cline
in
response
to
since
James
brought
up
four
one.
Nine
one
I
made
a
comment
that
I'm
on
the
milling
list,
that
was
I'm,
sure
lost
and
in
the
other
other
bits
it
would
be.
I
also
would
like
to
have
some
sort
of
of
must
four
four
one,
nine
one
we
have
you
know
I
heard
of
vendors,
who
will
basically
send
out
a
Pio
with
a
slash
56
and
l
equals
zero
so
that
you
can
try
to
install
a
route
that
at
least
captures
traffic
to
their
toward
the
Ritter
yeah.
B
G
That
will
still
keep
things
working
in
a
multi-link
device
where,
if
default
route
is
zero,
if
every
lifetime
is
zero
and
they
have
that,
we
need
to
know
we
need
to
not
do
that.
That's
pretty
happy
right,
yeah,
okay,
but
I
mean
what
they
do
it
because
it
works
right.
So
you
know
that's
that's
but
like
we
have
re
O's
in
theory
for
this
and
yeah,
it
seems
cleaner.
Okay,.
O
Well,
well,
we'll
take
a
look
at
that
text
and
try
to
clean
it
up.
Thank
you,
3G.
We
stuck
some
notes
in
the
node
requirements
about
you
know.
If
you're
reading
this
document,
you
should
go,
read
these
3G
things
if
you're
building
something
on
a
3G
network.
Oh
we
got
some
comments.
We'll
update
them
they're
listed
here.
O
E
Okay
answer
Krishnan,
so
one
of
the
authors
of
1766,
and
so
this
is
like
that
probably
a
gender
column.
Right
like
this,
like
a
1766,
it's
like
a
snapshot
of
the
3gpp
Network
at
that
point
and
probably
needs
to
get
revised,
so
that
is
already
a
revision
of
something
needed
before.
So
maybe
it's
like
time
to
revisit
it
in
v6
offs
right.
E
Look
at
like
what's
changed
since
then,
and
probably
like
give
a
better
update
on
things
so,
like
probably
sit
at
Med
and
talk
about
it
because
at
the
time
there
were
kind
of
two
different
v6
profiles
doing
the
rounds
in
v6
offs,
as
you
know
like
one
of
them
like
from
whatever
is
in
specs,
and
second
one
is
like
more
like
a.
What
do
we
want
in
black
for
all
the
transition
stuff
so
kind
of
we
had
the
disconnect
back,
then?
Maybe
we
can
revisit
it
now
and
see
like
okay?
I
G
O
E
I
E
I
guess
so,
so
the
alternative
Lauren's
our
right
is
to
like
no,
no,
the
alternative
is
to,
like
you
know,
kind
of
make
this
like
64:6
thirty-four
Biss
a
bit
milder
right
because
like
if
you
want
to
accommodate
all
the
changes
like
for
different
link
layers,
then
you
cannot
be
as
strong
as
the
requirement
so
like
what
is
saying.
Is
they
generally?
This
is
what
you
need
to
do
and
specifically
in
the
link
technology
like
you
might
do
something
different
like
same
thing.
We
do
for
like
six
loci.
E
So
so
so
this
too
is
like,
like,
like
you,
said,
there's
two
ways.
One
of
them
is,
we
can
say,
like
oh,
like
most
of
these
things
like
most
of
the
must
should
become
should
so
in
64
34.
If
you
want
to
accommodate
like
a
wide
variety
of
link
layers,
another
way
is
to
say
like
okay.
This
is
the
right
thing
to
do
unless
somebody
specifies
an
exception
and
says
why
right
so,
those
are
the
two
ways
to
go
forward.
Yeah
and.
O
V
Yeah
Tim
Chan,
so
exactly
and
with
it,
we've
kind
of
got
two
exceptions
in
in
the
update
here.
One
is
constrained,
nose
and
the
other
is
this.
Where
we're
just
pointing
it.
You
probably
want
to
look
at
this
rather
than
copy
it
all
into
here,
particularly
when
suresh
says
that
was
just
a
snapshot
anyway
and
probably
will
get
updated.
So
a
couple
of
examples
of
those
things
are
78
28
and
6603,
which
are
general
hosts,
but
you
wouldn't
do.
That
makes
it's
more
useful.
I
Forensic
leery
can't
we
just
say:
well,
if
you
support
a
tech,
a
link
layer
technology
that
has
broadcasts,
then
you
need
to
support
this.
If
you,
you
know
cuz
like
otherwise,
you
know
it's
kind
of
a
worthless
document
if
it's
like
generic
host
requirements,
but
you
can't
ever
use
this
on
any
real
link
layer
like
a
nor
do
we
even
have
it
then
like.
Why
even
have
six
words
before
yeah.
O
O
O
Yeah,
okay,
all
right!
So
then
this
is
where
this
is
going
to
come
up.
So
currently,
obviously
there's
an
ongoing
thread
on
the
discussion
of
DHCP.
The
way
we
have
it
listed
now
is
we
have
DHCP
stateful
as
it
should
in
the
case,
there
are
cases
where
host
should
implement
it,
knowing
that
they're
going
to
potentially
be
on
a
network
that
will
require
that
and
the
other
section
we're
adding
text
on
is
for
stateless.
V
In
China
as
it
is
to
clarify
what
the
two
slides
would
have
said,
the
first
one
on
the
options
is:
it's
a
must
on
80
106
yep,
and
it's
a
should
support
stateless
DHCP,
3
6.
If
you
expect
the
host
to
take
advantage
of
those
options
that
aren't
available
now
so
like
ntp
and
all
those
other
things
and
on
stateful
dhcpv6,
the
document
currently
says
should
implement
and
that's
currently
where
we're
at
okay.
O
I
Learn
Zachary
I
mean
everyone
will
just
say:
I
hate
these
v6
and
it's
true,
but
so,
but
the
thing
that
that
I,
that
that
I
have
a
problem
with
in
this
in
this
charge
is
like.
First
of
all,
we
say:
well,
stateful
is
optional.
What's
sorry,
stateless
is
optional.
Only
if
you
only
if
you
bla,
bla,
bla
and
then
but
stateful
is
assured
it's
a
kind
of
three
well.
I
In
more
in
general,
like
there's
a
conflict
between
what
we
recommend
in
various
different
places,
right,
that's
so
so
I
think
specifically
I.
Think,
first
of
all
like
if
you
in
the
same
breath,
we
cite
7/8
44,
which
has
basically
don't
do
DHCP.
Unless
you
have
no
other
choice
and
then
you
say
should
always
all
hosts
should
implement
the
HPV
6.
Now
you
know
that
seems
just
silly
because,
like
7
844,
if
you
read
it
carefully,
says
don't
do
HPV
6
stateful,
because
it's
bad
for
privacy
and
so
like
either
way.
I
It's
like
don't
cite
1744
or
we
say
you
know
we
we
or
we
cite
it,
and
we
say
here's
why
that
RFC
that
we
cited
two
lines
above
says:
don't
do
this,
but
you
have
to
do
this
anyway,
or
we
can
say
if
you're
a
host
that
cares
about
privacy,
then
you
then
the
should
doesn't
apply
to
you
but
like
we
have
to
resolve
this
conflict.
And
additionally
it's
my
reservation.
Everyone
will
say
that
I'm
on
crack
right,
but
in
it's
my
reservation.
I
Only
the
only
thing
that,
like
we
say
again,
link
there's
another
conflict
where
we
say
you
have
to
do.
You
should
do
dhcpv6,
because
there
are
networks
that
require
it
and
we
have
a
BCP
that
says
it
is
wrong
for
a
network
to
require
it.
We
do
not
recommend
that
so,
like
I'm,
just
saying
we
need
to
make
up
our
minds
here.
I
mean
you
know
yeah.
Well,
we
can't
that's
like
it's
just
all
credible
to
have
these
conflict
II
requirements
hi
there
jaruzelski,
hey.
I
You
get
a
life
yeah
loosen
up
dude,
you
know,
I
love,
you
man,
but
seriously
so
I
think
you
should
say
like
May
right
I
mean
cuz
I
still
use
the
HPV
6
extensively.
It's
not
going
anywhere.
Yeah
right,
truth
be
told.
You
know,
I
can
kind
of
sympathize
with
you,
like
you
know,
do
I
care
about
privacy.
There
there
my
devices
too,
you
know
and
I'm
gonna-
do
whatever
I
want
with
them
right.
Yeah.
Y
I
I
At
me
sets
a
super
positive
sign
right,
so
I
think
the
maze
probably
légende
me
with
the
recent
news
about
you
know
like
our
DNS
has
for
windows
and
stuff
I
got
I
mean
I'll,
be
honest.
We
I
mean
that's,
that's
like
basic
standard
plumbing,
but
thing
that
you
really
should
have
factoring
here.
That
was
like,
if
you
ever
want
to
do,
PD
right,
if
you
ever
wanted
to
kind
of
just
do
PD
without
an
na
right,
yeah.
G
O
I
I
I
O
I
I
M
I
Should
have
something
analogous
to
that,
for
you
know
that
includes
all
the
layer,
three
information
about
a
host
I
gotta
go
talk
to
Fred
to
see
where
that.
Maybe
you
guys
have
an
opinion.
You
know
Ilion
Bob,
but
yeah.
The
network
is
now
kind
of
smarter
right,
so
we
want
to
kind
of
kind
of
keep
going
in
that
direction.
So
all.
Z
Hi
I'm
Natalie
tournament
I'm,
one
of
the
ip6
trainers
that
Randy
talked
about
earlier
and
I
teach
around
a
thousand
network
operators
basic
ipv6
on
a
yearly
basis.
They
start
from
scratch.
They
sometimes
are
not
even
well
immersed
in
I
appreciate
for
it
we're
starting
to
get
a
problem,
because
if
I
do
the
training
course
and
I
say,
there's
no
ARP,
they
go
like
okay
and
then
I
say:
there's
no
net.
Z
They
go
like
what
and
then
I
say
yeah
there
might
not
be
DHCP
and
they
go
home
and
and
then
and
then
I
haven't
even
started.
Talk
about
the
40
extension
different
extension
had
a
problem
with
the
drop
rates,
the
transitioning
mechanisms
that
they're
facing
I
don't
know.
I
come
now
at
the
I'm,
not
normally
one
that
stands
at
the
mic,
but
it's
getting
now
harder
and
harder
to
bring
the
message
across
that
we're
doing
useful
stuff
for
them.
O
O
I
I
It
is
recommended
that
networks,
where
general
poplars
hosts
connect
to
so
like
not
a
cable,
modem
or
any
device.
No,
no
thermostat
a
general-purpose
host
those
networks.
It
is
not
recommended
that
they
require
that
you
ask
for
an
address
every
time
you
want
a
new
address
and
basically
that
kind
of
rules
out
the
HP
v6,
because
they
get
a
new
address.
You
have
to
ask.
So
that
is
our
current
best
practice.
I'm
saying
is
that
there's
a
conflict
with
with
was
with
this
tech,
so.
M
My
proposal
that
commonness
ionized
I
think
that
stainless
DHCP
should
be
supported
must
be
supported.
I
think
that
if
you
don't
have
that
in
the
document,
essentially,
you
have
a
whole
working
group.
That's
working
on
something
that
in
practice
is
not
usable,
so
either
requires
Dedalus
DHCP
here
or
close.
The
ACP
working
group
wow.
S
Barber
start,
as
was
said
on
the
list
on
the
BCP,
that
Lorenzo
refers
to
as
a
specific
use
case:
RFC,
whatever
64
34,
that's
being
revved
applies
to
all
nodes
yeah,
and
so
just
because
something
that
applies
to
all
nodes
that
a
particular
use
case
says,
and
this
specific
thing
we
actually
recommend
this
I,
don't
see
any
contradiction.
V
Tim
changes,
yeah,
I,
agree,
computable
with
what
Barbara
says,
I
think
the
advice
about
yeah
see
an
energy
profiles.
You're
talking
about
I,
see
I,
think
that's
good
advice,
but
having
the
should
in
there
in
terms
of
implementing
it
allows
you
then
to
have
tht
P
where
the
anonymity
isn't
an
issue
for
you
in
your
deployment.
It
seems
reasonable,
I,
don't
think.
That's
necessarily
a
conflict.
I
think
an
image
profile.
Advice
is
very
good
advice.
V
I
Just
saying
if
we
do
want
to
keep
the
stacks,
we
have
to
explain
why
two
lines
above
we
say
recite
something
that
says
prefer
slack
over
d-36
and
then
we
say
for
all
hosts,
even
those
that
want
to
implement
this
profile.
They
should
always
be
able
to
do
the
thing
that
we
don't
recommend.
That's
all
I'm,
saying
like
you
or
if
we
want
to
put
a
carve-out
in
there
saying
like
you
should
for,
but.
O
The
thing
I
want
to
add
here
is
it
doesn't
say
it
says
that
they
should
be
able
to
go
there.
It
doesn't
say
only
right
and
your
profile
is
really
clear
about
that.
It's
the
only
case
which
we
don't
say
anything
about
so
I
think
we're
okay
from
that
perspective
and
that
we're
saying
that
you
should
do
DHCP
you
can
have
both.
You
can
be
running
slack
and
DHCP
Porter.
I
Was
so
but
but
then
but
then
you
then
we
have
to
say
well,
you
know
a
way
of
resolving.
For
example,
one
way
of
resolving
the
conflict
with
seven
8:44
is
to
say
dude
HP
v6
address
assignment
only
as
a
last
resort.
If
slack
has
failed,
that's
a
way
of
resolving
those
two
conflicts,
because
otherwise
you
seven
844
you've
got
a
device.
So.
O
Here's
my
thing
here
with
that
is
that
this
is,
you
know,
you
know
what
they
should
implement.
It
doesn't
go
into
the
operational
of
the
network,
so
I,
don't
think
we
put
a
sentence
like
that,
but
again
I'm
with
I'm
with
Barbara
and
him,
and
that
I
don't
think
that
this
conflicts
directly
with
the
text.
That's
in
there
it's
not
saying
that
they
should
do
DHCP.
Only
we're
saying
hey,
you
should
have
the
bells
to
turn
on
DHCP,
but.
I
S
This
should
means,
unless
you
have
a
good
reason.
Rfc
7080
44
provides
a
really
good
reason
for
a
specific
use
case.
Do
not
do
this
should
ya,
and
that
is
exactly
the
way
it
should
work,
but
we
should
not
take
the
RFC
78
44
and
put
it
back
into
general
node
requirements.
We
have
specific
cases
in
our
access
networks
where
we
are
not
ever
going
to
be
providing
slack.
I
B
E
E
So
that's
one
of
the
case
you
covered,
if
I'm
sure
you
thought
of
it
right,
but
but
that's
like
a
valid
case,
and
that
would
cover
Barbara's
exception
right
because
only
8:44
says
like
like
do
dhcpv6
like
in
this
case.
Otherwise
do
slack
right,
that's
what
it
says
right
so,
but
that's
a
specific
exception.
It's
not
affiliate
or
slack.
It's
just
that
the
prefix
didn't
have
autonomous
configuration
enable.
E
So
that's
like
one
specific
thing
you
want
to
say
over
there
and
now,
with
the
ad
hat
on
I'm,
not
closing
the
DHCP
working
group
because,
like
there's
like
another
configuration
information
like
Tim
Anton
said
before,
that
needs
to
get
done
and
I
really
don't
want
to
like
redefine
stuff
in
arrays
again
like
every
single
piece.
Okay,
even
though,
like
at
some
point
in
the
past,
maybe
that
would
have
made
sense,
but
not
anymore,
right
like
and
so
yeah.
So
that's
not
an
option.
E
A
H
I'm,
a
butter
fat
lover
more
than
the
sugar
lover,
I'm,
a
sucker
for
pastry
I,
don't
care
if
they
like,
vanilla,
chocolate
or
strawberry.
My
job
is
to
enable
them
to
move
from
unhealthy
desserts
with
corn
syrup
in
them
to
good,
healthy
ice
cream.
H
This
may
means
that
I
must
that
not
must
I
should
make
it
easy
and
attractive
for
them.
If
they
like
vanilla,
they
should
be
able
to
get
vanilla
ice
cream
yeah.
If
they
like
chocolate,
they
should
be
able
to
get
chocolate.
Ice
cream.
Natalie
tried
to
tell
you
she's
out
there,
trying
to
show
these
people
the
ice
cream
and
they're
going.
What
I
am
walking
away?
O
I'll
be
quick
I'm.
The
only
last
thing
is
we're
going
to
obviously
update
all
of
the
changes
that
happen
with
the
80
to
100
and
the
8201,
and
then
the
last
thing
we're
gonna.
We
have
to
talk
about
probably
at
the
next
ITF
is
informational
or
PCP,
for
this
document
I
think
we're
leaning
towards
PCP,
but
wait
till
you
finish.
It.
B
AA
Right,
Fred
Templin
from
Boeing.
This
is
to
talk
about
a
draft
that
was
presented
at
the
last
IETF
and
we've
resolved
some
comments
that
have
posted
on
the
list
and
we
also
have
a
new
way
of
looking
at
these
route
information
options.
So
the
first
draft
was
posted
on
six
men
list
in
January,
as
draft
0.
0
comments
resulted
in
the
publication
of
a
draft
0-1
and
that
we've
got
more
comments
on
that
and
then
advanced
your
own
one
was
presented
at
IETF
98
in
March
and
from
the
IETF
98.
AA
AA
Enterprise
mobile
devices,
like
cell
phones
and
tablets,
aeronautical
communications,
something
like
an
airplane
talking
to
an
air
traffic
controller,
unmanned
air
cyst
networks,
even
for
vehicle-to-vehicle
communications
and
home
networks,
with
multiple
subnets
such
as
we
talked
about
in
home
net,
and
the
next
step
was.
We
want
to
ask
if
this
can
become
an
ipv6
working
group
document.
B
AA
B
AA
AA
B
AA
AA
AA
B
AA
B
AB
AA
AA
Assurance
yeah
we're
not
doing
that,
though.
What
what's
happening
is
that
the
source
is
asking
the
target
to.
Please
send
me
back
your
router
information
options.
It's
not
going
all
the
way
to
the
destination.
It's
only
going
to
the
target
and
saying
neighbor
solicitation
and
your
neighbor
advertiser
and
please
include
router
information
options.
When
you
send
me
the
neighbor
advertisement,
okay,.
G
L
D
AA
Depends
very
much
in
that
discussion
about
whether
we
can
have
longer
prefixes
than
64.
This
is
not
like
addressing.
This
is
prefix
and
routing
right.
So
so
the
the
target
should
send
back
its
largest
claimable
prefix,
and
if
that
largest
clan
will
release
is
a
slash
112,
then
it
sends
back
to
slash
112
and
that's
what
gets
put
into
the
sources
routing
table.
Then,
okay,
so
you
don't.
D
AA
The
way
we're
seeing
is
this
link
sanity,
check
and
working
is
that
the
outter
will
send
back
around
information
option
that
it
knows
the
target
has
at
least
that
much
of
a
prefix
and
then
that's
when
the
source
sends
the
neighbor
solicitation
to
the
target.
The
target
will
come
back
with
a
round
information
option.
They
get
sanity,
checked
against
what
the
redirect
told
it.
So
the
router
is
authoritative
for
the
link
the
source
and
target
get
to
know
each
other
through
the
router,
okay.
So,
okay,
so.
C
C
N
AA
C
N
AA
B
N
B
G
AA
I
But
if
you
don't,
then
it's
a
regression
right.
We
we
have
this.
This
works
today
using
four
eight
six,
one
right
with
Ras
and
our
iOS,
and
if
you
don't
allow
that
or
you
don't
build
it,
and
basically,
we've
got
this
black
hole,
we're
basically
building
black
holding
capability,
because
if
the
link
gets
remembered,
the
source
doesn't
update
its
whatever
database.
It's
using
to
track
where
that
which
prefixes
is
reading
to
target.
What.
AA
I
Why,
like
you're,
basically
saying
missus
scoped
to
links
only
where
Ras
are
too
expensive,
because
I,
don't
really
don't
see
if
you
could
sent
if
target,
could
send
an
RA
Y?
That
would
be
worse.
It
seems
like
strictly
better
in
all
ways.
So
maybe
we
should
just
discuss
if
you
want
to
take
this
forward.
You
can
just
scope
this
to
a
case
where
there's
there.
Some
reason
why
target
content,
Ras
well.
I
Fine,
but
on
certain
links
that
make
sense
on
certain
other
links.
It
doesn't
so
if
you,
if
you
scope
this
to
a
situation
where
you
can
only
which
this
this
this
whatever
standard
is,
this
becomes,
is
only
used
on
links
where
Ras
are
not
practical,
because
Rooter
is
gonna,
be
telling
source
this
stuff
right
so
like
Garuda
has
to
be
sending
RA
is
presumably
so
we
have
to.
You
know
it
this.
I
This
only
may,
since
when
reader
consent
are
raised
to
all
the
sources,
but
the
targets
can't
send
the
RAS,
because
some
asymmetry
in
the
number
of
hosts
involve
an
of
like
Pacific
characteristics
of
the
link
type.
So
maybe,
if
we
have
a
listen
appropriately,
an
appropriate
applicability
statement,
where
says
the
work
that
says
where
this
makes
sense,.
L
L
AA
L
B
M
Go
quick,
I'm,
Fernando
I
will
be
presenting
the
address,
Yoshi's
usage
recommendations
ID
the
last
provision
that
we
did.
It's
the
same
document
that
the
Christian
presented
at
the
last
ATF
meeting
as
a
quick
overview
of
the
problem
that
we
have
here,
essentially,
no
virtually
all
notes,
have
multiple
addresses
of
different
properties,
like
stability
properties,
different
scopes,
etc.
When
it
comes
to
our
NGO
in
our
resolution,
it's
all
red
well
specified
in
RFC
767
24.
M
However,
when
it
comes
to
say
irises
that
you'd
use
for
receiving
incoming
communications,
those
are
not
actually
well
specified
and
the
dominant
practice
is
essentially
to
buy
to
bind
service
port
to.
Essentially
all
the
available
addresses
or
actually
what
you
do
is
you
bind
the
divine
a
socket
to
the
wykel
wildcard
address?
M
There
are
some
problems
with
this
one
example.
This
was
a
well
known
example
of
some
raspbian
systems
in
which
they
were
communicating
with
an
outside
system
and
an
NTP
server
was
at
the
time
and
right
after
that
they
will
receive
a
poor
scan.
So
the
fact
of
doing
something
say
like
clean
site.
Client-Side
communications
essentially
exposed
them
to
in
this
particular
case.
Never
reckon
essence,
there
are
other.
M
So
what
are
possible
alternatives
to
that?
Well,
if
re
you
know
applications,
they
could.
You
know
just
enumerate
all
the
possible
addresses.
You
know
pick
the
addresses
that
are,
you
know
suitable
for
the
specific
application.
A
problem
with
the
you
know,
current
API
is
that
you
can
bind
specific
areas
like
one
address
or
all
of
them,
but
not
a
subset.
That's
as
much
as
you
can
do.
You
could
possibly,
for
example,
employ
different
sockets
so
for
each
socket
you
just
buying
one
address,
but
that's
problematic
for
different
reasons.
M
First
of
all,
it
tends
to
be
like
very
platform
dependent
and
non-portable
to
actually
learn
the
actual
addresses
that
you
have
on
the
system.
On
the
other
hand,
you
don't
really
want
applications
to
have
to
deal
with
this.
Obviously,
and
besides
that,
even
if
you
go
applications
to
do
that,
even
if
they
were
able
to
learn
the
addresses,
then
they
would
also
have
to
be
able
to
check
the
properties
of
the
addresses-
and
you
know
include
all
that
knowledge
from
the
applications
which
is
really
nice.
M
There
are
other
things
related
to
you
know,
IRS
usage
and
configuration,
which
is
you
know.
Nowadays
the
Aria
selection
is
perform
at
the
application
by
configuration
is
done
by
the
system,
so
you
might
have,
for
example,
applications
that
they
might
want
to
have
just
a
specific
IP
address
for
that
application,
instead
of
having
to
employ
the
ones
that
have
been
configured
by
the
system.
But
again
right
now,
that's
not
possible.
Okay,
because
it's
a
system
that
you
know
the
size
which
addresses
are
come,
fear
of
which
types
when
they
are
configured
or
change,
etc.
M
M
You
know
based
on
the
feedback
that
we
received
at
the
last
IETF
meaning,
and
that's
actually
like
a
question
that
we
have
for
the
working
group.
We
are
probably
thinking
about
focusing
the
document
on
the
problem
statement,
because
you
know
working
on
the
solutions
you
know
might
be
like
too
much
for
this
single
document
changes
that
we
apply
for
the
document.
Essentially,
some
reorganization
and
some
mini
minor
editorial
changes
and
among
the
things
that
we
did,
we
applied.
We
try
to
address
feedback
that
will
go
from
they.
They
tailor
as
far
as
I.
M
Remember
noting,
for
example,
that
when
it
comes
to
you
know
how
you
select,
which
addresses
you
know,
are
employed
for
an
application
or
I
personally
believe
that
they
say,
let's
say
the
most
and
I
say
correct
or
clean
way
to
do.
It
would
obviously
be
to
be
able
to.
You
know
specify
that
at
the
application
with
some
sort
of
API,
but
at
the
end
of
the
day
there
are
multiple
ways
in
which
you
can
do
that.
M
For
example,
if
you
were
able
to
specify
a
subset
of
the
addresses
at
the
API
level,
then
it
will
be
the
tcp/ip
stuck
itself.
That
would
be
doing
the
filtering
so,
depending
on
on
which
is
you
know,
the
incoming
communication
or
incoming
packet
arrives?
It
would
be
the
stuck
itself
discarded
in
the
pocket
or
except
in
the
packets.
Another
option
is
for
the
application
to
do
that.
M
Filtering,
obviously,
that's
suboptimal
for
a
number
of
reasons,
among
other
things,
because,
for
example,
if
you
were
trying
to
do
this
at
the
let's
say
for
TCP
applications,
that
would
mean
that
the
application
itself
would
would
already
have
to.
You
know,
accept
the
connection
and
only
after
that,
the
application
would
be
able,
for
example,
to
tear
down
that
connection
and
besides.
M
Obviously
that
means
that
every
application
will
have
to
really
bring
re-implement
these
all
the
stuff,
which
is
really
not
nice,
and
obviously
you
could
also
know,
for
example,
do
or
somehow
decide
which
addresses
are
are
allowed
for
incoming
incoming
communications
at
no
I
filtering
packets.
So,
for
example,
you
could,
let's
say
whitelist
some
specific
addresses
like
stable
addresses
on
which
you
might
want
to
receive
incoming
communications,
but
not
on
the
other
ones.
M
G
M
G
Actually
address
some
of
the
things
that
were
discussed
earlier
today.
This
is
an
API
I
think
we
should
have
the
applications
to
say.
Oh
I
want
to
address
and
by
the
way,
I
should
only
be
mine
and
because
there's
other
issues
here
as
well-
and
that
is
even
if
you
were
to
do
something
like
reuse,
the
ipv6
prefer
source
at
our
home
or
temper
whatever
it
is
for
listening.
G
AB
Eric
link
more
is
solution
space
you
may
be
interested
by
reading
PF
Fitzer
and
a
few
other
people
draft
on
provisioning
domain.
That
tends
to
give
you
partial
answer
on
this
and
is
also
another
European
funded
project
called
neat.
That
was
part
of
a
Catan
yesterday,
which
also
tries
to
get
again
a
post
socket
API
for
the
chosen.
M
AB
M
AB
For
what
specifically,
in
the
case
of
need
it,
basically,
the
application
can
say
requirement
and
characters
of
the
application.
Then
it
can't
a
complex
system
based
on
policies
and
blah
blah.
Let's
select
the
right
source
and
write
destinations
addresses
could
be
multiple
right
with
multi-part
CCP,
but.
AC
Tommy
Polly
Apple,
yes,
so
kind
of
going
on
that
needs
also
involved
with
more
broadly
adequate
apps
working
group,
which
is
kind
of
trying
to
work
on
like
a
post,
socket
API.
So
for
people
who
are
doing
client
API
is
like
us,
I
think
will
be
useful
out
of
here
is
to
you
know
not
necessarily
just
have
like
the
solution,
but
what
are
the
requirements
that
need
to
be
exposed
to
give
people
the
right
knobs
on
this?
AC
What
are
the
filters
that
could
be
applied
on
the
higher
level
service
description,
such
that
when
we
are
doing
potentially
a
high
level
connection?
That's
ending
up
going
on
multiple
interfaces
or
doing
multi
path
that
we
have
the
right
knobs
for
filtering
that
are
approved
appropriate
to
describe
this
and
having
it
in
terms
of
not
just
the
socket
API
would
be
great
because
you're,
not
always
using
that
yeah.
M
AD
Little
to
you,
willin
I
also
wanted
to
point
out
two
stuff
from
the
types
of
working
group
there's
malas
going
to
that
direction.
Fourth
is
my
own
rough,
on
socket
intents,
which
is
target
rather
to
the
client
side,
but
also
could
be
extended
in
this
direction.
So
say
it
just
by
saying
what
kind
of
easier
and
tending
for
opening
this
socket
on
a
more
generic
level
and
then
take
from
the
operating
system.
M
I
think
that,
in
the
case
you
know,
besides
the
you
know,
that
thing
or
having
an
API
that
you
might
like
specified,
intend,
and
it
might
come
up
with
the
addresses
that
are
appeared
for
that-
there's
also
supposed
to
be
like
a
document
whatever
this
one
or
some
other
one.
That
says
well
for
this
kind
of
intent.
These
are
the
properties
that
you
might
want
in
an
address.
Besides
the
API
itself,
sure.
B
So
from
what
I'm
hearing
I
mean
I'm
a
little
unsure
here-
or
you
know
this-
the
demarcation
point
here
between
you
know
the
internet
area
transport,
an
application-
and
you
know
if
this
is
a
you
know,
problem
statement
to
transport
or
above
or
certainly
don't
think
we
can
do
all
this
on
our
own
purely
in
six
months.
Oh
so,
I'm
I
think
I
need
to
go
back,
and
you
know
talk
to
our
ad
and
and
transport
people
to
see
where
this
work
is
best
done.
I
see,
Suresh
is
at
least
nori
yeah.
M
Thank
you
Dave
as
a
side
comment,
I,
think
that
you
know
I
understand
your
point.
I
think
that
you
know
when
it
comes
to
address
is
that
from
an
applications
point
of
view
you
know
they
might
be
disabled
to
use
or
not,
but
I
think
that
there's
another
part
for
my
point
of
view
that
you
know
belongs
in
sync,
but
in
six
month
is
the
fact
that
at
this
point
in
time
we
have
like
addresses
of
different
scopes
and
properties.
M
So
it's
that's
like
a
two,
but
we
are
not
providing
any
guidance
on
world
where,
when
you
should
use
which
one
like
you
might
want
to
do,
only
temporary
addresses
or
just
only
stable
or
you
might
want
to
do
both
and
in
which
cases
you
might
want.
You
might
want
to
use
one
or
another
or
or
addresses
of
different
scopes.
I
personally
believe
that
that
part,
that
specific
part
belongs
in
six-man.
D
I,
don't
have
an
opinion
on
where
this
should
be
real
working,
but
I
think
it's
great
that
we
get
like
this
is
done
in
tapster,
there's
been
in
int
area
but
DVDs,
and
that
there's
work
going
on
that
is
related
to
this
all
over
the
place,
so
that
we
could
inventory
that
at
least
on
the
list
as
well.
That
would
be
good,
so
just
and
I
new
support.
We
I
think
the
socket
API
is
very
old
that
the
four
along
programmers
it's
really
hard
to
use
it,
the
more
we
can
help
the
application.
D
Programmers,
the
better
the
end
users
are
going
to
be
able
to
efficiently
use
the
network.
So
I
think
we
need
to
do
I'm,
not
sure
that
we
need
to
do
work.
That's
so
the
ability
is
that's
done
here
or
not.
That's
contentious,
but
I
think
it
needs
to
be
done
and
we
need
a
replacement
for
the
socket
API
that
is
open
source
and
so
on,
and
it's
not
vendor
proprietor.
Y
Detailer,
that's
a
fine
discussion,
but
this
is
the
wrong
sto
for
that
there
are
other
SG
O's.
That
is
the
appropriate
discussion
in
and
that's
what
I
was
talking
about
this
organization.
My
opinion
should
do
abstract
api's,
which
is
ones
without
the
language
specific
binding,
meaning
it's
not
the
C
API
of
the
JavaScript
API.
Here's
the
set
of
input
not
parameter
is
that
any
particular
binding
should
have
here's
the
programming
model
of
what
we
want.
Applications
to
use
right.
Y
That
stuff
is
actually
really
good
for
the
IETF
to
do,
because
other
other
organizations
are
not
experts.
In
that
part,
they
looked
IETF
to
say
well,
what's
the
right
way
to
do
it
and
yeah
well
specify
the
way
to
do
it
in
the
in
JavaScript
will
specify
the
way
to
do
it
in
C++,
11
or
whatever.
It
is
right
and
so
they're
the
ones
that
have
expertise
in
the
language
specific
binding.
Y
So,
for
example,
when
the
IETF,
the
rfcs,
that
is
like
the
the
sockets
api's
and
the
multicast
sockets
api's
right,
we
send
them
over
to
the
austin
group,
which
is
the
group
that
owned
the
c
api's,
which
is
I,
Triple,
E
and
Oakland
Group,
and
it's
iso/iec
yeah
right
and
so
that
parent
that
that
triple
is
called
the
Austin
group
right.
They
publish
a
common
specs,
and
so
they
said
you're
doing
it
wrong.
Okay,
they
said,
for
example,
set
sock,
opt
is
a
rubout
API,
an
octal
is
a
really
bad
API.
Y
We
don't
add
any
new
socket
options.
We
don't
add
any
new
outlets,
because
I
used
to
have
people
up
and
think
well,
I'm,
just
gonna
add
these
socket
options
and
octal.
Those
are
the
bodies
that
says:
that's
not
how
we
do
it
that
language
anymore,
that's
a
deprecated
concept.
Okay,
the
concept
is
you
define
a
new
function,
for
example,
it's
what
they
told
us,
and
so
we
revved
the
API
in
the
RFC
this
before
we
made
it
to
become
an
RFC
to
say
well,
there's
actually
new
functions
in
an
appendix.
Y
We
said,
oh
and
if
you
happen
to
implement
those
functions,
be
a
Sokka
because
you'd
already
started
implementing
it.
Then
here
some
saw
adoptions
in
the
appendix.
So
as
that
style
of
discussions.
That
happens
when
you
go
to
external
review
and
that's
the
type
of
stuff
that
we
are
going
to
do
when
talking
about
a
specific
language.
D
B
David
I
understand
you
correctly.
You
would
agree
that
writing
a
problem
statement.
You
know
stating
that
we
are
all
these
different
types
of
addresses
and
there
are
different
use
cases
and
that's
something
that
has
to
be
reflected
to
applications
to
make
that
choice.
That's
something
we
could
do
here,
but
the
actual.
Y
You
can
break
the
problem
into
three
parts
and
at
least
two
of
them
are
good
in
the
IETF.
The
first
one,
as
you
mentioned,
is
the
problem
statement
requirements.
The
second
one
is
an
actual
abstract
API,
all
right.
Here's
the
programming
model.
We
think
you
should
actually
open
a
socket
or
something
that's
like
a
socket
and
do
operations
like
read
and
write
on
it
and
you
should
find-
and
you
should
listen-
that's
an
abstract,
API
right,
saying:
here's
how
to
express
that
in
C
or
C,
plus
our
JavaScript
is
the
concrete
one.
Y
It's
only
the
third
thing,
that's
out
of
scope.
If
you
say
we
have
a
model
which
is
we'd
like
to
enumerate
addresses
on
an
interface
we'd
like
to
get
properties
of
those
addresses
and
here's
the
set
of
properties.
You
want
to
expose
that's
what
we
should
be
doing
in
the
abstract.
Api
sets
absolutely
so
it's
not
just
the
first
part.
I
think.
The
second
part
is
also
important.
Okay,.
C
B
L
So
I'll
be
quick,
so
yeah.
We
all
know
that
if
you're
using
slack,
you
configure
IP
address
honor
on
a
host
and
then
there
are
few
conditions
when
host
might
stop
using
this
address.
Obviously,
when
we
for
lifetime
expire,
but
because
the
preferred
lifetime
default
value
is
what
seven
days
it
basically
never
happens,
you
can
explicitly
invalidated
by
saying
in
IP
I/o
the.
L
I
right
unfortunate,
sometimes
even
if
hosts
should
reset
the
interface
state,
it's
not
happening.
Sometimes
interface
stays
up
and
when
the
router
says
aerials
erase,
they
sometimes
not
received
or
sometimes
routers
do
not
send
them.
It's
all
led
to
very
bad
user
experience,
support
tickets
me
being
unhappy
and
so
on.
That's
why
I'm
here,
for
example,
I
have
four
scenarios
here
and
I've
seen
three
of
them
and
I've
been
told
about
first
one
sir
Automation
is
a
new
black.
Will
really
will
all
love
reconfiguring
routers
automatically
based
on
some
expected
state
of
the
network?
L
The
problem
is
slug
is
a
special
case
when
it's
not
enough
just
to
push
new
configuration,
you
need
to
explicitly
invalidate
the
previous
one.
So
let's
say
my
network
intents
they
changed,
and
now
this
particular
interface
has
different.
A
net
blockers
on
my
system
push
the
new
configuration,
but
how
about
hosts
do
not
know
that
they
should
stop
using
the
previous
one
right,
so
we
already
have
a
broken
connectivity
and
while
our
vendors
do
allow
us
to
use
this
beautiful
feature
of
rolling
back
the
configuration
to
the
previous
state
in
this
case
it
doesn't
help.
L
So,
even
if
my
support
guys
roll
back
the
configuration
again
now,
we
still
have
the
broken
state
of
the
network
dish,
because
some
hosts
still
using
old
addresses
some
hosts
are
using
new
ones
and
so
on.
So
in
this
case,
automation
sometimes
make
life
harder.
See.
Second
scenario:
we
are
doing
proper
renumber
include
same
right.
We
actually
push
in
the
correct
intermediate
configuration
to
invalidate
the
previous
state,
however
erase
unfortunately
multicast
and
unfortunately
multicast
is
not
very
reliable
Wi-Fi.
L
So
sometimes
hosts
might
not
receive
an
array
and
still
trying
to
use
all
address
again
broken
connectivity
again
out
emotional
layer.
If
again,
for
some
reason
my
network
is
configured
automatically
I
might
push
some
configuration.
Should
we
change
the
villain,
great
I'm,
changing
the
villain.
A
host
have
no
idea
that
address.
L
So,
theoretically
rule
5/5.
Might
help
in
some
scenarios,
because
ok,
new
router
new
lair
to
a
no
new
link
local
address
with
rule
5
5
host,
will
probably
pick
up
the
new
prefix.
However,
first
of
all
not
all
accurate
and
system
implementing
rule
5
5
and
secondly,
it
would
not
help
if
link
local
address
of
router
did
the
change.
For
example,
in
case
of
remembering
or
some
people,
love
explicitly
configure
a
VLP
link
local
address.
So
even
if
you
change
moved
to
another
network,
you
might
still
see
the
same
link
local,
so
proposed
solution.
L
Let's
just
introduce
another
second-to-last
rule
and
the
default
address
selection,
because,
if
host
received
one
pio
long
time
ago-
and
it
just
received
another
PA,
always
another
prefix
I
suspect
that
in
many
cases
the
most
recent
Pio
might
be
slightly
better
to
use
because
it
kind
of
more
fresh.
So
the
old
texts
we
have
very
last
rule
use
the
longest
prefix
match
actually
do
not
know
how
often
this
rule
is
actually
used.
So,
let's
add
another
one,
just
on
top
of
it
if
we
have
no
other
way
to
select.
L
So
if
you
have
no
other
tiebreaker
right,
let's
just
use
the
most
recent
PIR
we
have.
So
if
host
has
one
Te'o
received
long
time
ago
only
button
you
won,
let's
use
you
one
because
most
likely
it
would
be
better.
And
so
the
question
is:
is
it's
a
good
idea
or
shall
we
just
to
do
something
else?
So
is
the
problem.
I
Like
well,
but
if
it's
not,
if
it's
already
doing
this
and
it's
not
helping,
then
maybe
it's
not
very
you
yeah,
I
I'm.
I
don't
oppose
this.
I
I
think
I
think
the
Linux
stack
does
this
already
specifically,
it
adds
the
address.
It
adds
new
addresses
at
the
end
and
oh
I
think
it
always
uses
last
one,
but
it
doesn't
always
do
the
right
thing,
because,
depending
on
the
order
in
which
they
arrive,
things
might
be
correct
or
incorrect.
Specifically,
it's
particularly
bad.
I
I
L
No
because
if
you
have
multiple
routers,
ok,
so
it's
the
very
last
right.
There
are
other
rooms
on
top
of
these
right,
so
in
case,
if
you
could
not
use
anything
else,
because
if
you
have
other
rules,
rule
5
or
something
else,
yeah,
let's
use
this.
This
one
is
just
instead
of
use
your
longest
prefix
match.
L
O
Tim
winner
UHI
well
so
rule
eight
is
my
only
advice
here
was
a
I'm
a
little
nervous
about
implementations,
keeping
track
of
when
they
get
pios.
For
a
variety
of
reasons
haven't
tested
this,
my
preference
would
be
to
just
stick
to
the
preferred
lifetime.
You
rule
eight,
that's
pretty
complicated
to
tell
them
to
process
the
PIO
and
the
order
of
what
they
get
it.
My
advice
would
be
to
just
do
it
based
on
the
lifetimes,
so
you
said:
if
they
can't
process
it
to
do
this
should
be.
O
G
Y
The
I
understand
what
you're
trying
to
do
I
think
somebody
else
mentioned,
there's
issue
if
you
have
two
different
routers
with
different
prefixes
and
they
happen
to
be
configure
two
different
preferred
lifetimes,
they're
refreshing,
you
know
here
and
there
or
whatever
but
you're,
just
saying
well,
you're,
just
going
to
beat
the
longest
matching
prefix
and
and
keep
everything
else
the
same,
and
so
maybe
that's
not
so
bad.
That's.
My
first
comment.
Second
comment
is
that
I
think
this
behavior
is
already
allowed
and
the
existing
RFC?
Y
L
L
Y
AE
L
B
AF
So,
anyway,
everybody
I'm
going
to
talk
about
the
interior
provisioning
domain
draft,
the
first
iteration,
those
are
the
authors,
I'm
Esther
and
it's
quite
good
fit
actually
after
the
two
previous
presentations
which
have
been
talking
about
address
selection.
These
are
examples
where
you
can
actually
have
more
addresses
to
pick
from
when
you
have
multiple
interfaces,
one
from
your
phone,
one
from
your
Wi-Fi
one
from
your
wire
and
actually
even
when
you're
connected
to
some
interfaces
on
some
link.
AF
Well,
in
the
end,
you
can
be
connected
to
different
services
like
multiple
ISPs
or
service,
like
like
a
VPN.
So
the
way
we
used
to
do
that
is
like
well
host
would
typically
pick
one
of
the
interfaces
that
they
have
and
ignore
the
others
like
use
the
wired,
because
we
assume
that
wire
is
better
than
Wi-Fi
right.
AF
This
is
obviously
not
the
best
way
to
operate
and
on
the
network
side,
when
we
wanted
to
provide
multiple
services
well,
we
would
classify
the
traffic
on
one
side
and
not
at
the
odds
at
the
exit
of
the
network.
This
is
not
exactly
how
we
want
to
operate.
That
I
think
there
is
a
good
progress
overall
in
the
ipv6
specifications
to
go
to
a
tube
going
through
a
path
where
we
can
have
a
way
better
design.
So
the
first
thing
to
do
is
obviously
to
assign
address
multiple
addresses
to
host
that.
AF
We
know
how
to
do
already.
The
host
can
support
multiple
addresses
and
we
are
talking
about
so
service
selection.
We
have
been
designing
a
solution
like
that.
Where
you
get
addresses
from
different
is
field
from
different
services
in
whole,
net
that's
specified,
and
there
is
work
being
done
and
I
would
like
to
apologize,
because
that
draft
ID
is
absolutely
not
the
right
one.
It's
a
it
has
been
adopted
since
then,
and
it's
like
the
third
iteration
from
Jen's
work
and
that's
for
corporate
network.
AF
The
second
step
is
to
teach
the
host
be
able
to
be
more
clever
about
how
they
pick
as
most
addresses.
So
one
solution
is
obviously
like
MPT
CP
to
just
use
all
the
addresses
or
many
of
them
and
just
use
those
that
were
all
the
solutions
are
relying
on
the
fact
that
host
will
be
able
to
make
more
clever
decision-
and
you
see
based
on
the
previous
presentations,
that
there
is
work
to
improve
the
way
the
hosts
behave
in
terms
of
sauce
and
resolution.
AF
But
the
problem
right
now
and
we
are
here.
The
final
point
point
is
that
the
hosts
have
to
deal
with
very
few
information
when
they
have
to
select
the
source
address,
they
yeah,
they
can
use
the
router,
they
have
the
pios,
the
more
specific
routes,
the
router
preference,
these
kind
of
things-
and
we
have
an
algorithm
for
that,
but
they
don't
exactly
know
what
they
are
connected
to,
and
so
that's
the
purpose
of
this
raft.
AF
AF
That's
the
definition
from
me,
and
so
we
want
to
identify
different
shades,
the
provisioning
domains
with
names.
Those
names
are
fully
qualified
domain
names
and
I'm.
Going
to
that
later.
The
reason
why
so
we
want
to
identify
those.
The
second
thing
we
want
to
do
and
that's
the
key
point
is
that
once
you
are
able
to
add,
I
did
identify
the
DVDs.
You
want
to
get
more
information
about
the
nature,
turn
the
characteristics
of
each
DVD,
because
the
hosts
will
I
mean
the
application
may
want
may
have
some
certain
needs.
AF
That
cannot
only
be
fulfilled
by
some
properties
in
the
links,
and
you
want
to
be
able
to
to
know
those
properties.
So
first
here
is
an
array
option
that
we
are
proposing.
You
can
have
at
most
one
of
those
per
array,
the
name
the
PD
ID
is
a
fully
qualified
domain
name
as
I
made
as
I
mentioned.
You
put
this
option
in
the
array
when
you
want
an
implicit
DVD,
if
you
don't
put
it
there.
AF
Well,
you
have
automatically
an
implicit
DVD
for
those
hosts
that
support
pivot
is
the
legacy
bit
is,
is
used
to
be
able
to
attach
the
ipv4
configuration
to
a
given
PVD
because
we
don't
want
to
modify
a,
but
you
can
still
know
that
the
ipv4
comes
from
the
east
for
validity.
The
h
bits
is
a
part
of
the
interesting
part.
It's
a
bit
that
tells
you
that
you
can
get
more
information
about
the
PVD,
doing
an
HTTP
request
and
that's
next
slide.
AF
You
also
have
a
sequence
number,
because
everything
in
our
eyes
is
push
based.
So
you
want
to
be
able
to
push
some
new
data,
some
new
DVD
properties,
so
you
just
increment
the
sequence
number
to
do
that
and
you
have
a
lifetime
well.
The
second
step
is
once
you
get
the
pivot
Eid
from
the
array
based
on
that
if
the
HPT
set.
So
if
you
know
there
there
is
some
more
PDD
additional
data
available.
AF
You
construct
an
HTTP
request
using
the
PVD
ID,
so
the
fully
qualified
domain
name-
and
you
use
this
path
here,
so
it
the
in
the
draft
its
PVD
JSON.
We
got
some
feedback
married
next
revision.
It's
going
to
be
dot,
well-known
activity
proposed
the
point
being
that
the
the
information
that
you
get
from,
that
the
additional
information
is
attached
with
the
network
information
that
you
got
from
the
RA
and
from
the
HCP
there
is
the
HIV.
This
is
an
example
of
what
you
can
get
in
this
additional
data.
AF
So,
most
importantly,
I
mean
the
first
useful
part.
Is
you
get
a
name?
So
the
user
is
actually
going
able
to
see
what
it's
connected
to
a
localized,
localized
name
as
well
for
link
different
languages.
You
have
an
expiration
date.
You
put
the
prefixes
that
you're
going
to
use
for
numbering
disability,
so
you
can
the
the
host
and
validate
its
own
address
based
on
these
projects
and
you
put
the
characteristics,
the
characteristics
of
the
link.
Those
are
just
informational.
AF
Finally,
once
you
get
all
this
information
in
this
example
like,
if
you
have
a
horse,
that
is
good
that
is
receiving
two
arrays
with
two
different
PVD
IDs
kind
of
classified
the
different
configuration
information
that
you
get.
You
have,
in
fact,
the
information
that
you
get
from
attached
with
one
PVD
and
the
one
that
you
got
from
a
different
pivot.
AF
The
point
of
this
draft
is
not
to
completely
modify
the
way
the
hosts
do:
source
address,
selection
or
default
route
address
selection,
it's
not
about
a
new
algorithm
or
all
that
we
don't
want
to
modify
it.
We
just
want
to
get
some
more
information
and
allow
the
applications
based
on
yeah
on
an
application
basis
to
behave
according
to
well
on
a
specific
set
of
pvd's
like
on
this
example.
You
would
get
some
application
using
one.
Pvd
is
some
other
application
using
another
one
and
maybe
some
application
using
multiple
of
them.
AF
S
AF
Have
minute
minutes:
okay,
open
wrt,
iOS,
some
kind
of
experimental
work
from
to
me
and
there
was
integration
in
the
need
project.
There
will
be
other
presentation
in
the
interior
and
capture
photo
working
group
and
I'm
very
interested
in
getting
six-man
feedback,
and
particularly
this
array
option
and
overall,
if
you
think
it's
a
good
idea
to
to
get
that
additional
information.
L
AF
L
AF
So
the
point
of
the
prefix
here
is
to
be
able
to
validate
its
host
address.
So
if
you
get
a
Pio
based
on
this
PA
Pio
attached
with
a
PID,
you
do
the
request
and
from
that
request
to
get
this
JSON
and
Indo
Jason,
you
find
a
perfect.
Then
you
just
verify
that
your
source
address
is
within
that
perfect.
You
don't
really
have
to
validate
cross
validate
to
JSON
objects,
I
think.
Y
B
AA
So
the
arrow
address
happens
when
a
node
n
receives
a
unique
ipv6
prefix
delegation,
for
example,
2001
DBA,
1
2
/
6,
before
through
whatever
means,
whether
it
be
the
HCP
v6
prefix
delegation,
manual,
configuration
or
through
whatever
means
the
note
and
then
embed
snap
prefix
in
the
suffix
of
the
ipv6
link
local
prefix.
So
in
this
example,
we
have
fe80
colon
colon
2001,
DB
8,
1
2,
so
the
delegated
prefix
appears
in
the
interface
identifier
of
the
link,
local
prefix,
and
we
call
this
the
arrow
address.
AA
So
were
the
advantages
of
using
an
arrow
address.
First
of
all,
you
get
stateless,
ipv6
link
local
address
auto-configuration.
You
avoid
the
need
for
dad,
because
the
ipv6
prefix
delegation
is
unique,
so
the
arrow
address
must
also
be
unique.
It
can
be
used
as
the
source
and
destination
address
of
ipv6
neighbor
discovery
messages
and
it
also
links
ipv6
neighboring
discovery
in
particularly
ipv6
neighbor
cache
with
ipv6
forwarding,
because
you
have
prefix
information
in
the
neighbor
cache
you've
also
got
prefix
information
in
the
forwarding
table.
AA
Prefix
length
issues
came
up
on
the
the
mailing
list.
The
ipv6
link,
a
local
prefix
according
to
the
specs,
is
fe80
colon
colon,
slash
10,
but
RFC
42
91
link
local
address
configuration
assumes
on
colon,
slash
64.
AA
Therefore,
the
embedded
prefix
length
is
restricted
to
slash
64,
but
what
if
we
could
use
a
shorter
fe80,
zero
of
prefix?
For
example,
if
we
had
fe80
colon
colon
slash,
10
and
embedded
the
2001
DBA,
we
would
have
this
lawn
looking
clean
here.
That
starts
at
the
tenth
bit
then
beds
the
2001
address
in
the
tenth
bed.
The
pros
of
that
there
are
no
wasted
bits
and
you
can
embed
prefixes
up
2/1
18.
AA
The
cons
is,
that's
not
easy
to
read
or
parse
and
when
I
say
parse
I
mean
looking
at
the
address
and
programmatically
looking
at
the
words
of
the
one
hand,
28
that
address
another
alternatives
that
we
could
use
the
prefix
fe80
calling
1/16,
and
then
we
can
embed
the
2001
DBA
starting
in
the
17th
bit,
so
that
I
prints
nicely.
The
pros
are
that
it
reads:
well,
and
it
can
embed
prefixes
up
to
a
/.
AA
112
cons
is
that
waste
6
bits
of
the
leading
16
bits
use
cases
and
next
steps
use
cases,
would
be
enterprise,
mobile
devices
like
cell
phones
and
tablets,
and
so
forth.
Aeronautical
communications
for
airplanes
to
talk
to
air
traffic
controllers
unmanned,
the
air
system
networks
for
vehicle
to
be
able
to
communications
and
home
networks
with
multiple
subnets,
such
as
whole
net
I
I,
want
to
ask
the
sixth
working
question
at
this
time,
but
I'd
like
to
get
some
questions
if
we
can
fit
them
in
the
next
minute.
B
B
We
will
print
throughout
the
lease
comment
on
what
we
should
do
with
the
with
the
draft
documents.
I
think
we'll
take
that
to
the
list.
I
think
it's
pretty
clear
that
we'll
keep
addressing
architecture
park
if
anyone
volunteers
to
do
the
changes
necessary
to
privacy,
extensions,
please
let
us
know
on
the
list.