►
From YouTube: IETF115-SNAC-20221110-0930
Description
SNAC meeting session at IETF115
2022/11/10 0930
https://datatracker.ietf.org/meeting/115/proceedings/
A
B
A
B
A
B
Yeah,
so
we
were
on
meet
Echo
usability
slide.
You
guys
are
familiar
with
it.
Please
make
sure
you
are
in
the
queue
before
you
come
to
the
mic,
and
also
this
is
a
signing
tool
for
blue
sheets,
so
definitely
sign
in
next
slide.
Please
here's
our
agenda.
This
set
of
slides,
followed
by
first
presentation
from
Ted
on
stud
Networks.
B
Second,
one
Pascal's
prefix
registration,
and
we
will
have
plenty
of
time
to
talk
about
next
steps
and
these
two
documents
so
I
encourage.
We
will
do
most
of
the
questions
related
to
the
document
as
the
presentations
go
along
and
then
any
general
question
for
the
work
group.
We
can
delay
it
to
later
on.
That's
next
slide,
so
this
is
the
first
snack
meeting
for
those
who
haven't
followed
the
progress
from
buff
to
today's
meeting
and
on
mailing
list.
B
F
F
That's
that
usually
works
poorly,
because
I
tend
to
wave
my
hand
around,
and
then
you
can't
hear
me
so
let's
not
do
that.
Okay!
So
we've!
You
know,
we've
had
a
number
of
discussions
about
forming
the
working
group
and
that
was
based
on
you
know
some
ideas
that
already
existed
so
I've
had
a
document.
That's
been
lying
around
I've
been
trying
to
to
figure
out
how
to
publish
it
for
a
while,
and
so
that's
that
served
as
the
starting
point
for
what
I
hope
will
be.
F
So
this
document,
the
goal
is
just
the
basic
stub
Network
functionality.
We
have
two
main
items
in
our
Charter:
one
of
them
is
basic
functionality,
so
we're
not,
depending
on
infrastructure,
support,
we're
not
requiring
changes
to
hosts
on
infrastructure
and
then,
depending
on
the
target
type
of
stub
Network.
F
So
what
it
had
was,
you
know
how
we
maintain
a
usable,
IPv6
prefix
on
adjacent
infrastructure
and
the
idea
there
is
that
the
adjacent
infrastructure
link
may
not
actually
support
IPv6
and
in
order
to
accomplish
what
we
need
to
do
without
doing
bridging
or
network
address
translation,
we
kind
of
need
to
use
IPv6.
So
if
the
adjacent
infrastructure
doesn't
have
a
prefix,
we
have
to
provide
it,
and
so
there's
there's
actually
in
the
original
document.
It
just
basically
described
how
that
was
done.
F
It
didn't
give
a
state
machine
or
anything
like
that.
It
described
how
to
do
SRP
registration
for
the
stub
Network,
the
Assumption
was
for
Native
2.15.4
network.
We
really
don't
want
to
use
multicast
and
that
actually
works
well
with
the
stub
Network
model,
because
we
don't
want
to
bridge
multicast
either,
and
so
so
using
Service
registration
protocol,
which
is
a
dnssd
document,
gives
us
the
functionality
that
we
need
without
requiring
multicast.
F
It
talked
about
using
the
original
document,
talked
about
using
the
advertising
proxy
to
advertise
whatever
was
registered
in
SRP
on
infrastructure.
It
didn't
talk
a
whole
lot
about
any
other
service
Discovery.
It
was
mentioned,
but
not
in
detail,
and
then
I
talked
about
how
to
use
nas64
to
connect
to
the
cloud.
The
motivation
there
is
that
we
feel
like
we
can
assume
that,
at
least
in
the
short
term,
a
typical
infrastructure
Network
probably
has
ipv4
service
on
it.
F
Probably
some
of
you
guys
already
know
most
of
the
history
of
this,
but
this
is
just
for
those
folks
that
maybe
haven't
been
following
this
very
closely.
So
what
I
changed
in
the
current
document
is
I
removed?
A
bunch
of
text
so
I
removed
the
text
about
dhcpv6
and
I,
removed
all
the
text
about
reachability
and
discoverability
from
non-adjacent
links
both
of
those
require
cooperation
from
the
infrastructure.
F
It's
not
clear
that
I
mean
the
cooperation
from
the
infrastructure
for
DHCP.
V6
is
already
something
that
you
can
get.
So
that's
a
little
bit
different
than
the
other
cooperation.
The
other
cooperation
is.
We
actually
need
the
infrastructure
to
to
wire
the
stub
Network
resolver
functionality
into
or
DNS
functionality
into
the
into
the
stub
net
into
the
infrastructure.
F
Network
DNS
resolver,
so
that's
kind
of
hard
so
that
that
we
took
out
took
out
of
the
basic
document
and
then
the
problem
statement
document
was
kind
of
long
and
detailed
and
talked
about
a
whole
bunch
of
different
possible
solutions
as
well
as
the
problem.
And
but
there
was
some
useful
text
in
the
document.
F
So
the
introduction
is
a
little
more
detailed
and
hopefully
more
helpful
and
then
I
gotta
start
on
putting
in
state
machines.
So
I
did
a
state
machine
for
the
management
of
the
on
on
link,
Auto
configuration
prefix
for
the
infrastructure
Network
and
the
idea
here
is
it's
not
so
much
to
prescribe
how
you
should
implement
it
as
to
give
you
an
idea
of
what
the
problems
are
that
you
have
to
deal
with
and
to
propose
a
way
of
solving
it
previously
I
just
kind
of
said.
F
This
is
what
you
need
to
do:
here's
how
it
ought
to
behave.
Good
luck
and
I
got
a
fair
amount
of
feedback
on
that.
That
was
not
enough
detail,
so
I
added
that
detail
and
I
think
that
there's
probably
similar
detail
needed
for
some
of
the
other
things
that
the
stub
network
does,
but
that's
not
currently
in
the
document
next
slide.
F
So
what's
in
the
document
now
we
have
sorry.
If
this
is
a
bit
of
an
eye
chart,
we
have
maintenance
of
the
usable
prefix.
So
that's
the
infrastructure,
IPv6
prefix.
If
there's
already
an
IPv6
prefix
on
infrastructure,
we
don't
have
to
do
anything,
but
if
there's
not,
then
we
need
to
provide
one
and
it
has
to
be
usable,
meaning
like
an
Android
phone
has
to
be
able
to
get
an
IP
address.
F
F
Similarly,
we
have
to
advertise
routes
to
the
adjacent
infrastructure
on
the
stub
Network.
That's
a
bit
architecture
dependent
for
the
for
the
infrastructure
Network.
We
assume
that
we're
using
Ras
for
the
stub
Network.
We
can't
really
assume
that
in
sort
of
the
the
current
use
case
that
we're
actually
using
this,
for
we
don't
do
ra.
D
F
Thread
is
an
802.15.4
based
mesh
Network
and
it
does
not
do
ras.
It
uses
a
different
mechanism
for
advertising
this
information.
So
the
general
assumption
in
the
document
is
we.
You
know
if
you're
doing
a
Wi-Fi,
stub
Network,
then
you're
probably
going
to
use
Ras,
but
if
you're
not,
then
you're,
probably
going
to
do
something
weird
and
exciting
and
different.
So
then
the
document
talks
about
service
advertising
and
Discovery.
This
is
actually
there's
a
bunch
of
things
you
have
to
do
to
make
this
work
in
all
cases.
F
So
there's
two
problems,
one
is
advertising
and
the
other
is
Discovery
and
each
of
those
problems
is
handled
differently,
depending
on
whether
it's
on
the
stub
Network
or
on
the
infrastructure
Network.
So
on
the
stub
Network
for
advertising,
we
use
SRP
so
we're
assuming
that
this
requires
host
changes
or
not
host
changes
we're
since
it's
kind
of
a
green
field
environment.
We
just
assume
that
we
can
say
the
host
uses
SRP
and
then
for
discovery
on
the
stub
Network.
F
There's
two
different
types
of
hosts
you
might
want
to
discover.
One
of
them
is
hosts
that
are
on
the
infrastructure,
Network
and
the
other
is
hosts
that
are
on
the
stub,
Network
and
actually
an
additional
Point
here
is
that
there
could
be
more
than
one
stud
Network
connected
to
the
infra
to
the
same
infrastructure
Network,
and
we
actually
really
want
the
stub
Network
hosts
to
be
able
to
discover
stub
Network
hosts
on
other
stub
networks
as
well.
That's
not
currently
talked
about
in
detail
in
the
document.
F
So
so
Discovery
proxy
sits
on
the
on
the
stub
router
and
does
queries
on
the
infrastructure
Network
to
satisfy
queries
from
stub
Network
hosts
and
then
for
stub
Network
hosts
It's,
relatively
straightforward.
It's
just
an
authoritative
Zone.
You
do
DNS
queries
to
it,
so
so
the
the
SRP
updates
in
authoritative
Zone-
and
we
just
answer
questions
out
of
that
zone
now
for
discovery
on
the
adjacent
infrastructure.
F
First
of
all,
we
don't
need
to
worry
about
adjacent
infrastructure
hosts
discovering
each
other,
because
we
assume
that
that's
already
working,
that's
not
our
problem,
and
so
we
sort
of
we
leverage
that
to
also
make
it
possible
to
discover
stub
Network
hosts.
So
instead
of
doing
DNS
queries
to
the
authoritative
Zone,
that's
populated
by
SRP,
we
answer
questions
that
we
see
on
mdns
using
the
contents
of
that
zone.
F
That's
called
an
advertising
proxy,
so
that's
pretty
straightforward
and
then
the
other
thing
that's
covered
in
the
document
is
the
maintenance
of
the
NAT
64
prefix
and
again
that's
going
to
need
a
state
machine
and
it
currently
doesn't
have
one
so
there's
there's
further
work
to
do
there.
So
that's
the
current
state
of
the
document
next
slide.
F
F
You
know
unless
we
just
say
that
the
stub
Network
hosts
can't
reach
the
internet
and
I,
don't
think
we're
really
able
to
say
that
so
so
that
means
that
we
have
to.
We
have
to
provide
some
way
for
stub
Network
hosts
to
download
firmware,
updates
and
potentially
talk
to
cloud
services.
We
can't
assume
IPv6
connectivity,
even
if
the
home
has
IPv6
connectivity.
F
It
may
not
support
prefix
delegation,
but
it
almost
certainly
has
ipd4
connectivity
of
some
in
some
form,
even
if
that's
not
64
right,
so
it
could
be
that
you've
got
an
IPv6
only
home,
but
the
ISP
is
providing
it
with
Nat
64
so
that
you
can
reach
hosts
on
the
ipv4
internet.
That's
fine!
That
works.
We
we
have
to
support
that
as
well.
So,
in
other
words,
we're
using
nat64
in
this
case,
but
we're
not
providing
that
64.
we're
just
taking
advantage
of
existing
that
64..
F
So
now
we
could
of
course
say
you
know
if
you
don't
have
the
HTTP
V6
prefix
delegation,
then
tough
luck.
You
can't
talk
to
the
internet,
but
I,
don't
think
we
can
really
say
that
so
unfortunately,
I
don't
like
I
would
like
to
put
dhcpv6
prefix
delegation
into
this
document.
But
this
isn't
a
reason
to
do
that.
That's
not
going
to
solve
this
problem!
So
that's
the
NAT
64
question
I
think
we
concluded
that
Nat
64
is
required,
but
I'm
not
positive,
that
everybody
fully
agrees
with
that.
F
F
F
F
Okay-
okay,
great
so
next
slide,
and
then
you
know
remaining
work.
I
think
you
know
we
don't
have
a
state
machine
for
Nat
64.,
it's
possible.
We
need
other
state
machines.
Certainly,
my
implementation
has
a
state
machine
for
managing
the
presence
of
the
SRP
server.
It's
not
clear
that
we
need
that
in
this
document,
but
maybe
we
do
and
we're
relying
on
a
document.
That's
currently
a
working
group
document
in
the
dnssd
working
group,
the
advertising
proxy
document.
F
F
Another
question
is
we
talk
about
the
potential
for
a
partitioned,
stub
Network
and
what
we
need
to
do.
In
that
case,
we
don't
have
a
whole
lot
of
text
about
that.
The
reason
for
that
is
because
partitioning
I
think
is
a
very
application,
or
you
know
a
very
Network
Technology
specific
thing
so,
like
thread
has
a
way
that
it
does
partitioning
I.
Don't
think
we
want
to
be
talking
about
thread
in
this
document,
so
therefore
we
can't
really
talk
too
much
about
how
thread
does
partitioning.
F
F
But
you
know
I'm
curious
what
the
working
group
thinks
about
that
too
next
slide,
and
then
basically
my
goal
in
getting
up
here
and
talking
to
you
guys
and
telling
you
about
this
awesome
document
that
I've
written
is
that
I
hope
the
working
group
will
adopt
it
and
I
hope
people
will
read
it.
It
would
be
great
if
somebody
wanted
to
do
an
implementation.
F
I
realize
that's
a
big
ask,
but
that'll
be
cool
so,
and
you
know,
like
Pascal,
is,
is
doing
some
interesting,
six
low
pan
stuff
that
I
don't
really
have
any
visibility
to
so
it'd
be
interesting.
I
know,
Pascal!
Does
some
some
application
stuff
it'd
be
interesting
if
Pascal's
interested
in
doing
that
or
anybody
I
don't
want
to
single
you
out
Pascal.
Just
just
you
know,
I
happen
to
know
that
you
that
you're
doing
stuff
in
this
space,
so
that's
I,
think
that's
it
next
slide
turns
in
the
next
slide.
G
G
Need
to
do:
okay,
no
sorry,
Michael
Richardson!
So
in
the
pathological
case
that
the
ISP
is
Forward
Thinking
and
has
provided
the
customers
with
V6
only
networks
with
a
ISP
provided,
Nat
64.,
then,
if
we
don't
have
DHCP
v6pd,
then
we
have
a
failure
right.
We
don't
get
internet
connectivity
because
we
can't
not.
We
can't
Nat
six
four
ourselves
because
there's
no
V4
on
the
local
network,
because
they're
using
Nat,
six,
four
right,
yeah.
H
C
D
G
F
H
So
everything
as
the
entity
for
this
I
was
really
concerned
when
I
saw
nat64
coming
up,
because
I
want
to
get
a
very
small
document,
implementable
right.
So
I
don't
want
to
repeat
from
that
as
you
know,
but
you
convinced
me
right
so
keep
it
there
but
and
then
Michael.
You
stole
my
words
about
DHCP
yeah,
yeah,.
I
Tim
Winters
QA
Cafe,
so
couple
things,
I
I
definitely
think
we
should
put
PD
in
this
document.
I,
definitely
think
we
should
I'm
going
to
write
a
draft
for
PD
on
the
back
side
of
CPS,
because
yeah
a
lot
of
them
have
servers
every
all
of
them
have
servers,
but
they
don't
turn
on
PD.
So
they
have
these
giant
prefixes
that
they
don't
do
much
with
right.
So
I
think
we
probably
need
to
give
them
some
guidance
for
sure.
So
I'm
definitely
going
to
put
something
I.
I
I,
wouldn't
object
to
that
I
yeah
I
mean
7084
is
in
a
weird
spot.
It
was
always
in
V6,
Ops,
I
guess
I
could
live
there.
The
only
other
thing
I
thought
you
should
talk
more
about
is
the
reachability.
You
asked
about
that.
I
read
it
and
that'll
be
a
problem
for
people
would
be
my
guess.
Okay,
so
I
think
you're
gonna
need
to
put
a
little
more
detail.
I'll
send
some
notes
about.
D
Hi
Bob
hinden,
so
I
first
of
all,
I
may
not
be
up
to
speed
on
this.
So
that's
what
I
say
may
be
wrong,
but
seems
to
me
for
now
six
four:
if
there's
not
six,
maybe
this
is
what
Michael
said:
if
there's
not
64
at
the
highest,
you
know
the
ISP
Edge,
then
I
don't
think
this.
Should
this
whatever
this
is
defining
shouldn't
have
to
do
anything
it
because
if
it
doesn't
exist.
F
F
So
there
is
one
little
wrinkle
there,
which
is
that
when
we
wrote
the
threads
back-
and
we
don't
necessarily
have
to
carry
this
over
to
this
spec
when
we
wrote
the
thread
spec,
we
decided
that
we
really
didn't
like
the
idea
of
breaking
DNS
SEC
and
therefore
that
it
was
a
responsibility
of
the
host.
That's
doing
the
lookup
to
do
the
synthesis
and
so
that
had
some
follow-on
implications
on
like
actually
the
stub
Network
router.
It
does
kind
of
need
to
do
a
little
bit
of
assistance.
F
Maybe
maybe
not
I
mean
you
could
just
do
the
the
regular
ipv4
and
lead
on
arpa
query,
but
we
might
want
to
do
ras
that
you
know
if
it's.
If
it's
a,
if
it's
a
Wi-Fi
network,
we
might
want
to
do
ras
in
the
case
of
thread,
we
actually
put
something
in
the
thread
network
data
that
says:
here's
your
IP,
here's,
your
NAT
64
prefix,.
D
F
C
F
J
J
K
K
And
then
we
had
a
conversation.
Like
that's
the
point
we
we
want
hosts
to
be
able
to
communicate,
and
the
other
thing
is
that
we're
not
trying
to
our
goal
is
not
to
build
a
little
private
overlay.
That
can't
talk
to
anything
else
right.
Our
ideal
situation
is
I
mean
in
this
case.
It's
thread
that
we're
talking
about,
but
so
I'll
use.
That
example
it'd
be
nice.
If
every
thread
node
had
a
global
unicast
IPv6
address
that
it
can
freely
use
to.
K
With
any
host
using
any
protocol
that
runs
over
ipp6,
the
stuff
about
making
up,
ulas
and
advertising
them
in
Ras
is
just
a
fallback
for
when
the
full
connectivity
is
not
present
right.
So
we
definitely
want
to
focus
on
on
the
ideal
case
and
then
talk
about
how
do
we
get
something?
That's
not
quite
as
good
when
we
don't
have
everything
we
want
yeah.
It's
a
good
point.
F
C
F
B
F
E
So,
as
I
can
say,
a
few
words
yeah,
please
go
so
I'm,
not
quite
as
sure
as
you
make
it
that
not
six
four
is
unavoidable.
There
are
other
possibilities,
so
Michael
answered
quite
convincingly
why
there
are
good
reasons
to
the
net
6-4,
but
I
would
still
like
to
mention
that
there
are
other
possibilities.
My
personal
favorite
would
be
to
have
ipv4
and
IPv6
tunnels.
E
So
Michael
answered
quite
convincingly
that
this
requires
a
full
ipv4
stack
on
the
step.
Node,
which
might
be
a
problem,
but
still
I'd
like
us
to
consider
it,
and
one
thing
I
would
also
like
us
to
consider,
is
whether
we
really
need
full
ipv4
connectivity,
so
perhaps
I'm
going
to
get
yelled
at
right
now,
but
if
all
we
need
is
HTTP
access,
wouldn't
it
be
enough
to
have
a
sox5
proxy
on
the
stub
router.
F
E
But
the
point
I'm
trying
to
make
here
so
that
was
mentioned
on
the
list-
I
think
I'm
not
alone
and
wanting
the
net
six
four
stuff
to
be
in
a
separate
spec.
So
it
can
be
discussed
separately
of
the
very
good,
very
interesting
and
very
good
work.
That's
in
the
rest
of
this
document
and
I'm
wondering
whether
you
would
consider
splitting
it
out
into
a
different
document
so
that
this
can
more
easily
be
discussed
separately.
F
I
mean
I
I,
think
you
know
my
experience
with
with
you
know
it's
a
very
common
thing
for
people
to
say:
let's
split
the
document
up
and
my
experience
with
that
is
that
quite
frequently
what
winds
up
happening
is
we
split
the
document
up.
We
write
several
different
documents.
We
wind
up
with
a
lot
of
text,
that's
fairly
confusing
and
ultimately
the
working
group
says
why
don't
we
just
like
take
all
of
these
documents
like?
Why
do
we
have
so
many
separate
documents
like
two
years
later,
when
everybody's
forgotten?
F
Why
we
have
so
many
separate
documents?
Why
don't
we
put
these
documents
back
together
and
you
know
just
make
one
document:
it's
a
lot
simpler,
so
I
think
we
need
to
have
an
actual
reason
to
do
that,
and
not
just
that.
We
think
that
nat64
is
less
yummy
than
than
you
know
end
to
end,
because
you
know
I
agree
that
it's
less
yummy,
but
you.
L
It's
good
egg
yeah,
just
just
erect
on
the
previous
point,
was
mentioning
maybe
to
have
ipv4
also
on
the
stop
Network
notes,
but
yeah.
Of
course
we
have
also
six
slope
and
type
networks
that
we
want
to
connect
a
stop
networks.
So
threat
is
one
example
of
those
yeah,
so
it's
not
really
feasible.
I
would
say
to
you
know,
change
those
into
supporting
ipv4,
which
they
don't.
L
So
that
seems
not
a
good
path,
I
think.
But
my
question
was
actually
on
yeah.
The
problem
statement.
Ted
also
mentioned
that
so
I
also
see
sometimes
in
working
group
as
separate
problem
statement
document
we
don't
seem
to
have
one.
Is
there
some
sort
of
History
of
how
it
how
it
has
evolved
or
that
we
have
the
problem
stated
in
your
document
or
so.
B
F
Whether
the
work
group
needs
to
publish
it
is
actually
the
important
part,
so
we
did
actually
write
a
problem
statement
document.
It
expired
on
Monday,
and
so
the
question
is:
do
we
actually
need
the
problem
statement
document
or
is
the
text
that
I
pulled
out
of
the
problem
statement
document
and
put
in
this
document
sufficient
I?
Don't
know
the
answer
to
that?
If.
A
So
mark
I'm
responsible
for
it
for
that
the
problem
statement
was
kind
of
all
over
the
place,
not
necessarily
in
the
bad
way.
It's
just
that
it
was
comprehensive,
comprehensive.
Thank
you
for
all
the
possible
cases
right
and
then
you
know
to
have,
and
we
discussed
to
have
two
different
deliverables.
A
J
Yeah
they're
into
quality
I
think
they're
I
mean
you
kind
of
mostly
need
a
problem
statement
when
people
don't
agree
that
there's
a
problem
or
they
don't
agree
what
the
problem
is.
I
think
this
is
pretty
clear.
You've
got
some
other
Tech
and
it
wants
to
like
plug
into
something.
That's
already
there
and
talk
to
the
internet.
I
think
that's
pretty
pretty
clear
and
useful
problem
to
solve.
Oh
and
by
the
way
I
mean
I
mentioned
this
to
to
John
and
some
other
conversation.
J
If
someone
doesn't
want
to
implement
PD
because
they're
like
this
is
never
going
to
happen
in
the
real
world
and
it's
on
them
to
basically
make
the
solution
work
in
other
cases,
right
I
think
it's
important
to
have
one
sort
of
State
machine
that
covers
all
those
cases
and
only
one
supported
solution
where
all
of
these
things
are
part
of
the
protocol
and
in
terms
of
the
size
of
the
document.
Yeah
I
mean
I.
Think,
if
we
really
do
want
to
split
up
I
would
very
much
advise
again
splitting
up.
J
You
know
things
that,
like
could
be
added
on
later.
It's
going
to
result
in
bad
interoperability
and
like
hard
to
debug.
Instead,
you
know
if
we
want
to
split
something
up:
yeah
put
put
the
service
Discovery
bits
somewhere
else
and
put
the
connectivity
bits
all
in
one
doc,
and
they
will
contain
Asics
for
a
pde
and
everything
and
the
RAS
and
everything
right
so
but
I
don't
think
you
necessarily
have
to
split
it
up.
That's
sort
of
you
know
just
something
for
the
working
group
to
do
inside.
J
M
M
So
this
is
Pascal
from
Cisco
and
I'm
talking
about
a
document
which
is
being
proposed
at
six
flow.
So
it's
not
a
document
for
this
working
group,
but
what
is
being
discussed
in
this
document
could
be
a
tool
in
the
toolbox
that
you
might
decide
to
use
in
building
your
solution.
Certainly
it's
not
a
comprehensive
solution
like
a
document
that
you're
doing,
but
it's
it's
one
element
that
could
be
considered
in
in
the
solution.
M
M
The
first
thing
that
we
found
was
that
the
use
of
broadcast
was
a
killer,
so
we
we
had
to
separate
the
broadcast
domain,
the
concept
of
Links
at
the
layer
2
with
what
we
use
for
subnetting
and
IP
Links
at
layer
3.,
and
doing
that
we
found
that
we
are
not
a
need
to
use
routing
pretty
much
everywhere
in
what
we're
doing,
but
also
that
we
could
not
choose
neighbor
Discovery,
as
it
was
as
a
reliable
mechanism
to
learn
which
IP
addresses
were
present
in
the
network.
So
we
could
inject
them
in
the
routing.
M
If
we
don't
have
a
deterministic
knowledge
of
which
IP
is
where,
then,
there
is
no
way
to
inject
that
either
in
an
iot
Network
for
routing
or
any
VPN
or
whatever.
So
we
we
worked
on
that.
We
we
looked
at
neighbor
Discovery
and
we
considered
how
it
could
be
done
in
such
a
way
that
effectively
we
could
know
deterministically,
which
addresses
were
we.
We
could
not
choose
slack
because
it
relies
on
broadcast,
but
we
still
needed
address
of
the
configuration.
M
M
8545
is
not
limited.
20
proxies
an
abstract
contract
between
a
host
and
a
router
in
that
contract.
The
host
can
say
Please,
Mr
Roto,
whatever
you're
doing
for
writing.
Please
do
it
for
me,
so
that
can
be
a
deep
proxy
in
the
case
of
rsc9010,
it's
going
to
be
a
repo,
it
can
be
a
rift.
I
mean
it's.
There
is
a
draft
for
adpn
as
well
as
soon
as
you
have
a
deterministic
knowledge
of
the
IP
address.
Now
the
routing
can
manipulate
it.
M
The
other
thing
that
was
not
possible
with
with
ND
was
securing
this.
This
contract
wanted
to
make
sure
that
if
somebody
else
comes
in
somewhere
and
says,
hey
I'm
him,
there
was
no
way
you
would
get
the
ownership
of
the
address
no
way
to
get
the
address
stolen.
So
we
are
very
c8928
which
is
basically
associating
a
something
derived
from
a
private
key,
basically
so
some
crypto
mechanism
that
will
that
basically
does
not
in
the
pki
to
start
with,
it
is
just
a
pair
of
keys
that
the
device
will
Auto
conf.
M
At
the
same
time,
it
took
off
the
address,
but
then
the
infrastructure
will
associate
the
two
and
another
thing
they
have
to
say
about.
Those
things
is
there
is
a
abstract
registrar
which
is
not
the
nssd,
because
we
design
without
it,
but
it
is.
It
is
an
abstract
registrar
which
knows
exactly
which
addresses
are
present
on
this
network
and
which
cryptographic
token
is
associated
with
those
addresses.
M
The
way
this
abstract
registrar
is
implemented
depends
on
the
use
case.
In
the
case
of
evpn.
It
is
bgp
itself
right,
the
whole
infrast,
the
whole
information
is
replicated
in
each
in
each
P.
Basically,
they
know
whether
the
the
vxlance
tunnels
are.
They
know
which
addresses
are
at
the
end
of
the
tunnels.
They
also
know
the
cryptographic
tokens
associated
with
those
choices
in
the
case
of
8929
it's
going
to
be.
M
If
you're
doing
repo,
we
expect
definitely
some
form
of
central
registrar
to
maintain
that
thing,
something
like
list,
for
instance,
so
the
registrar
itself
is
very
abstract
there
isn't.
If,
if
you
guys
would
decide
this
dnssd,
it
could
be
the
nssd
just
to
say:
okay,
they
are
not
imposing
anyway,
it's
an
abstract
thing,
so
the
family
keeps
being
extended
and
the
reason
why
is
those
protocols
that
we
Define
six
slope
and
then
the
repo
extra
are
effectively
deployed
in
the
con?
M
In
the
context
of
smart
grid,
we
managed
to
build
subnets
with
thousands
of
nodes
and
they
are
effectively
deployed
and
running
today
and
the
the
alliance,
the
equivalence
of
the
Wi-Fi
Alliance,
that
does,
that
is
called
wise
Sun
and
why
Sun
decided
that
they
needed
multicast,
so
I
try
for
five.
We
don't
need
MLD,
we
don't
do
any
form
of
solicit
dot,
multicast
or
anything
like
that.
M
We,
we
are
all
based
on
stateful
knowledge
of
every
address
in
the
network,
so
there
is
no
need
to
pull
from
solicit
non-multicas
because
there
is
no
lookup
in
the
end,
there
is
no
discovery
now
so
still
they
discovered
they
needed
MLG
because
they
wanted
some
some
degree
of
multicast
and
for
the
same
reason
they
didn't
want
broadcast
for
unique
snd.
Basically,
they
could
not
for
afford
the
broadcasts
which
are
coming
with
MLT
either.
M
So
what
we
decided
to
do
with
this
multicast
registration
thing
is
to
use
the
exact
same
mechanism
to
proactively
tell
the
network
hey
I'm,
subscribing
to
this
address,
as
opposed
to
having
the
network
pool
as
you
design
for
low
power.
You
need
to
realize
that
those
low
power
devices
are
sleeping
a
lot.
You
have
to
let
the
low
power
devices
control
when
they
wake
and
it's
on
their
demand
that
something
can
happen
when
those
devices
wake
up.
M
M
Since
we
have
this
Global
Knowledge
of
every
address,
then
the
concept
of
broadcasting
for
lookup
doesn't
make
any
sense
either.
So
we
have
this
unicast
lookup,
which
is
another
abstraction
on
how
you
go
and
consult
the
6lbr
to
basically
tell
you
which
addresses
exist,
and
if
you
have
a
broadcast
domain
we
can
reach
them.
M
Now
there
is
a
new
member
in
this
family.
We
introduced
it
to
iutfs
ago
in
one
of
30
in
113,
and
the
concept
here
is
when
we
build
those
those
Ripple
very
wide
Ripple
networks.
We
never
want
them
to
be
Transit
Network.
We
didn't
never
thought
repo
as
a
Transit
Network
thing
and
it
could
become
such
if
you
have
a
need
like
that.
There
are
all
the
mechanisms
for
it,
but
it
was
never
thought
to
be
a
Transit
Network
because
it's
an
iot
in
typically
an
iot
Network.
M
M
M
So
the
question
is:
would
it
make
sense
to
do
the
exact
same
thing
as
we
did
for
any
cast
multicast
and
unicast
addresses,
but
for
prefixes
as
well?
So
as
we
can
advertise
in
a
protocol
independent
fashion,
the
direct
reachability
of
one
prefix
are
supposed
to
say:
hey
I
have
this
address
if
you
need
to
contact
this
address,
come
to
me
I'm
directly,
connected
to
its
my
address.
Could
we
now
say
the
same
thing
for
a
slash?
Something
first
usage
obviously
is
I,
have
a
slash,
64.
M
I'm,
a
host
with
stack
642
to
The
Host
could
I
just
tell
my
ripple,
Network,
hey
I.
Have
this
slash
64.
inject,
that
for
me
please,
and
then
it
could
also
be
redistribution.
When
you
do
rotting
protocols,
one
thing
you're
used
to
is
hey.
You
have
a
prefix
behind
you
which
is
enrolled
by
a
other
protocol.
You
don't
really
know
where
that
protocol
is,
but
you
know
that
you
can
reach
that
prefix
you're
connected
to
it.
You
don't
need
rotting
with
cost
and
multi-hop
you're
directly
connected
to
it.
M
M
M
All
this
says
is
hey
I
have
this
address
and
there
is
there
a
bit
if
you're
doing
any
form
of
writing.
Do
it
for
me,
please,
because
I
won't
be
doing
it
myself.
So
if
it's
not,
the
L
participates
to
Ripple,
it
will
not
set
the
orbit,
but
if
the
node
doesn't
participate
to
report
and
hopes
that
the
router
will
render
the
service,
then
it
will
set
the
orbit
write
for
me.
M
M
What
we
don't
have
today
is
the
equivalent
of
nine
one
of
nine
zero
one
zero.
Where,
instead
of
saying
a
I,
have
this
address,
you
would
like
to
say
a
I
have
this
prefix
okay.
So
again,
what
we
are
doing
is
in
this
interface
is
completely
agnostic
to
whatever
routing
is
happening
up
there.
It's
just
a
matter
of
saying
through
a
simple
ND
message:
I'm
this
guy
I,
have
this
slash,
64
or
I'm
directly
connected
to
that
network.
If
you
have
packets
for
that
Network,
you
can
trust
me
pass
it
to
me.
M
Next
slide,
please
so,
since
I
followed,
your
work
and
and
I
saw
that
this
group
was
being
from
I
thought:
hey,
let's
let
us
at
least
share
to
see
if
there
are
things
we
could
do
in
common
or
if
you
would
be
interested
in
in
extending
or
using
what
we
are
doing
since
we
are
beginning
this
work,
it's
completely
elastic
and
if
you
would
need
it
and
and
could
use
it
in
your
solution
and
you
need
some
changes
on
some
adaptation.
It's
completely
easy
at
this
state
of
time.
M
So
I
basically
wrote
two
sections
in
this
document
to
show
two
use
cases
that
seem
to
to
map
what
you're
doing
and
the
first
use
case.
Is
you
get
a
single
link
here
which
is
a
share,
so
so
we
have
what
we
call
a
shared
link,
basically
very
ancient
way
of
doing
things.
Well,
you
have
more
than
one
prefix
on
this
shared
link
and
you've
basically
had
this.
M
M
Another
thing
that
could
happen
is,
if
you
have
an
IP
network
up
there,
for
instance,
this
is
an
industrial
plant.
You
could
also
decide
if
the
arc
bit
is
set.
Remember
this
is
controlled
by
the
orbit.
If
the
orbit
is
set-
and
there
is
ospf
on
the
right,
you
could
always
make
it
so
that
the
prefix
in
orange
or
the
prefix
you
see
it
here,
I
think
this
is
yellow.
M
Well,
anyway,
you
could
decide
that
they
are
injected
or
not.
This
is
controlled
by
the
protocol.
There
is
this
orbit
which
says
rod
for
me
please
right.
So
all
this
is
in
the
specification
next
slide,
please
and
it's
a
very,
very
stupid
extension
to
h505,
just
the
capability
to
to
expose
a
prefix
Lux.
Basically,
now
there
is
always
there
is
also
the
case,
and
this
is
more
for
cloud
application.
Remember
I
told
you
you
can
redistribute
it
505
in
anything
you
like
can
be
VPN.
M
There
is
a
big
draft
which
explains
how
that
works
by
vpm
when
in
a
case
like
this,
knowing
that
kubernetes,
mostly
works
for
V4
V6
is
now
available,
but
it
mostly
works
for
V4,
and
you
know
we
do
all
those
overlays
and
games.
We
could
also
do
a
flat
V6
and
if
we
do
a
flat
V6.
Basically
we
provide
this
usual
96
96
for
a
given
a
private
Network
and
we
basically
replace
IP
and
IP
by
ipv4
in
IPv6
address.
M
So
we
replace
a
tunnel
by
an
address
inside
the
address
and
we
get
pretty
much
the
same
result.
So
the
way
8505
works
today
is
what
we
call
the
arrow
option,
which
is
placed
in
DNS.
So
the
host
sends
an
NS
message
to
the
router
say:
hey
I'd
like
to
use
this
address,
I
have
autographed
it.
It
comes
from
the
sky.
You
don't
have
to
know
how
I
built
it,
but
I
would
like
to
be
using
it
and
the
router
says
fine,
it's
not
a
duplicate.
You
can
have
it
if
we
do
it
for
prefix.
M
Do
we
still
want
to
use
NS?
Would
we
like
to
use
arise
to
carry
the
arrow?
Should
we
still
call
it
a
row
since
our
romance
address
registration?
Should
it
be
sros,
tab,
step,
prefix
or
whatever
Steps
step
registration
option,
and
we
we
there
are
things
that
we
need
to
discuss
just
about
naming
and
which
message
should
carry
this
thing,
and
this
message
that
you
see
on
the
right
is:
how
is
the
abstract
way
of
talking
to
the
nssd?
It's
how
you
go
and
register
and
say:
hey
I.
Have
this
prefix
next
slide?
M
Please
and
then
again
the
prefix
can
be
obtained
by
you
know
the
httpd
or
whatever
else,
and
that's
something
we
need
to
discuss.
What
Becomes
of
that.
That's
the
nasty
question
because
remember
for
address.
We
expect
Auto
configuration,
so
we
expl.
We
expect
to
do
Auto
conference
as
usual,
and
then
you
go
to
this
registrar
through
your
router.
M
Could
we
auto-conf
prefix,
that's
part
of
the
name
of
your
working
group.
Would
you
really
like
to
do
a
tokens
like
not
even
PD
but
really
autokov,
so
you,
you,
basically
expose
a
slash
48
in
your
arrays,
and
the
guy
picks
just
an
arbitrary
two
bytes
and
registers
that
and
since
we
can
do
it
for
addresses,
we
could
also
say
Hey.
M
M
M
So
last
but
not
least,
compared
to
when
the
we
have
zero
trust
built
in
the
protocol,
the
host,
when
it
configures
and
address,
or
a
set
of
addresses
it
can
do
a
single
keeper
for
multiple
addresses.
It
will
also
Auto,
confer
keeper
I'm,
not
talking
about
a
pki
I'm,
just
talking
about
a
single
key
pair.
M
The
what
happens
is
since
the
network
keeps
track
of
all
the
addresses
which
are
registered.
It
can
also
keep
track
of
a
cryptographic
token
that
was
Associated
to
the
address
the
first
time
it
was
created,
so
basically
the
host
when
it
put
the
constant
address
and
registers
it
for
the
first
time
in
the
other
option
there
is
this
fraud
ownership,
verifier
field,
this
Rover
field,
which
can
contain
a
crypto
ID.
M
M
It
would
be
challenged
for
the
ownership
of
that
address
whether
it
is
for
injecting
in
the
routing
whether
it
is
for
Mobility.
The
node
was
there,
it's
here
for
the
router,
it
just
shows
up.
Is
it
really
the
owner?
There
will
be
this
Challenge
and
this
challenge
basically
a
pair
of
nouns
and
and
validating
that
the
the
host
as
the
private
care
associated
with
that
crypto
token
so
compared
to
CGA.
This
is
immensely
simple
because
we
don't.
M
M
Okay,
so
compared
to
CGA,
which
is
really
really
complicated.
This
is
just
a
simple
cryptographic
operation,
where
the
host
will
prove
that
it
has
the
token
that
is
associated
in
the
infra.
With
this
address,
so
you
can
form
a
neutralize.
First.
Come
first
serve
you
on
this
address
the
associated.
With
this
token
now
it
cannot
be
stolen
and
you
can
do
Savvy
and
you
can
do
all
those
games.
B
B
M
Where
we
are
is,
this
is
a
very
new
work.
It's
just
for
now.
It's
just
describes
that
we
already
have
with
8505
but
for
prefixes
can
be
used
to
advertise
not
to
stubby
areas
in
repo
or
in
any
protocol.
I
know
whether
we
do
auto
conf
is
to
be
discussed,
whether
we
call
things
arrays
and
arrays
is
to
be
discussed.
B
C
M
So
I
have
a
big
list
of
things.
We
could
be
doing
policies
articles
load,
balancing
when
you
register
to
multiple,
mostly
in
the
case
of
EDP,
and
if
you
register
to
multiple
leaves
you
could
influence
the
weather.
Balancing
is
done
back
to
you
just
the
way
we
have
wrought
our
preference.
We
could
also
have
equal
cost,
multipath,
balancing
type
of
signaling.
You
mean
all
sorts
of
stuff.
We
could
be
doing.
F
C
F
Why
not
just
use
DHCP
because
it's
already
defined,
but
there
are
a
couple
things
here
that
I
think
are
particularly
interesting.
I
think
you
know
this
is
not
really
a
snack
thing
per
se.
So
I
don't
know
that
necessary.
This
is
necessarily
the
right
place
to
talk
about
it,
but
since
we're
talking
about
it
being
able
to
D
broadcastify
ND
on
Wi-Fi
networks
is
a
very
attractive
thing.
F
Our
experience
with
Wi-Fi
networks
at
this
point
is
that
multicast
works
just
fine
as
long
as
the
network
is
is
in
a
good
state,
but
when
the
network
stats
get
a
little
ugly,
then
multicast
stops
working.
So
well
you
wind
up
having
to
re-transmit
a
lot.
It
might
take
a
minute
to
get
an
answer.
Instead
of
you
know,
200
milliseconds.
M
F
So
so
doing
things
to
to
avoid
turning
on
the
multicast
functionality
in
Wi-Fi
is
is
probably
something
worth
talking
about,
maybe
not
here,
but
you
know
I
I
I'd
like
to
see
that
happen
somewhere
and
I.
Think
some
of
the
stuff
you
talked
about
here
is
highly
applicable.
To
that
I
mean
I.
Think
some
of
it's.
You
know
you
some
of
us
intended
for
that.
But
so
that's
good.
F
F
Mentioned
that
yeah,
but
yeah
so,
but
but
when
I
looked
at
RFC
9010,
it's
like
about
Ripple,
so
so
so
having
something
that
allows
us
to
inject
routes
is
definitely
something
we'll
want
for
the
follow-on
document.
We
need
to
be
able
to
do
that.
Somehow
I
mean
one
of
the
ways
that
we
could
do.
That
is
just
by
having
the
the
assuming
that
the
the
DHCP
PD
will
result
in
the
route
being
injected
into
the
into
the
routing
plane.
But.
F
Right
but
but
but
the
point
is
you
know
we
we
in
this
working
group
could
sort
of
hand
wave
about
it,
because
that's
how
that's
how
PD
generally
Works
nowadays
I
mean
we
and
there
isn't
a
spec
that
says
how
it
works.
On
the
other
hand,
it
would
be
kind
of
nice
if
there
were
a
spec
that
says
how
it
works.
So
I
think
that
would
be
work
worth
doing
so,
generally
speaking,
I'm
I
think
there's
a
lot
of
good
stuff
in
here.
F
No,
so
well
so
the
six
low
specific
stuff
that
you're
working
on
I
think
does
belong
in
six
low.
But
there's
some
there's
some
interesting
stuff
in
here.
That
I
think
we
need
for
more
use
cases
than
just
six
low
pan,
and
so
that's
why
I'm
saying?
Maybe
that's
not
the
place
to
do
it.
But
you
know
because
we
I
mean
to
some
extent.
M
F
J
Hey
yeah,
Lorenzo,
clear,
I'm
flattered
that
you
think
I
have
an
influence
to,
like
you,
know,
change
standards
and
Destroy
standards
and
create
standards.
Thank
you.
You
know
seriously.
So
I
had
like
I
had
a
couple
of
thoughts
on
this
regarding
snack,
specifically
one
one
General
thing
I
just
wanted
to
say
before.
J
That
is
that
if
you
want
to
do
Aro
for
energy
saving
purposes,
that's
a
good,
that's
a
sort
of
like
solid
motivation
right,
but
the
trade-off
there
is
that
if
the
nodes
are
sleepy,
that
kind
of
means
you
can't
change
anything
on
the
network,
because
you
can't
talk
to
them.
So
on
a
home
network
which
might
potentially
change
dynamically.
For
example,
a
lot
of
European
isps
do
flash
your
numbering
once
a
day.
Sometimes
even
more
often
you
kind
of
need
the
ability
to
talk
to
those
nodes
anyway
to
update
them.
J
M
I
can
answer
that
before
you
ask
the
next
question
Yeah.
So
basically,
the
oi
of
iot
devices
is
that
they
can
sleep.
Obviously,
when
they
sleep,
they
don't
do
anything
so
they
are.
They
don't
need
to
know
that
the
prefix
has
changed.
They
only
need
to
know
when
they
wake
up
so
saving
energy
is
for
the
first
thing
allowing
going
away
from
multicast
and
broadcast.
You
need
to
completely
stop
that
game.
Second
thing
you
have
to
learn.
When
you
do
low
energy
is
allowing
for
sleep.
M
Those
devices
can
slip
one
percent
of
that
time,
ten
percent
of
the
time,
or
even
as
much
as
cats.
Now
as
long
as
you,
sleep,
yeah
yeah,
that's
a
lot
as
long
as
you
sleep,
you
don't
need
to
know
there
was
this
flash
remembering
what
you
want
to
see
happen
is
when
the
the
dude
wakes
up,
then
he
gets
this
array
which
will
tell
you
hey
the
pios
change,
and
now
it
will
auto-confa
new,
address
and
register
that,
but
during
the
sleep
period,
Then.
J
I
mean
it's
very
good
for
it's
very
good
for
a
managed
Network,
where
you
know
the
prefix
doesn't
change
and
you
have
loads
of
nodes
but
I.
Think
I,
guess
that's
sort
of
my
broader
point
for
a
home
network.
I
think
the
trade-offs
are
a
bit
different.
The
battery
the
devices
may
or
may
not
have
more
power.
I
think
the
Sleepy
devices
in
this
model
are
probably
gonna,
really
be
like
more
in
the
802-15
for
cloud
right,
so
they
are
sort
of
like
behind
the
BR
and.
M
C
J
It's
actually
like
a
more
complicated
but
anyway.
So
one
thing
I
wanted
to
say
is
in
this
specifically
for
snack
doesn't
seem
that
useful,
because
if
you
do,
if
you
try
to
inject
a
prefix
into
them
into
the
mesh
by
a
you
know,
Pro
whatever
it
is,
it
is
called.
That's
only
going
to
go
to
the
to
the
things
on
a
network
that
speak
the
protocol
and
in
particular,
like
Legacy,
hosts,
won't
know
this.
And
so
what
happens?
Is
it?
J
Let's
say
that
you
get
a
prefix
from
the
Gateway
and,
first
of
all,
that's
going
to
plumb
a
route
to
you
anyway.
So
the
traffic
will
like
from
a
traffic
from
a
legacy
host,
will
go
up
and
compare,
pin
down
you're
better
off,
sending
an
RA
on
the
network
that,
with
a
with
an
Rio,
so
that
the
traffic
from
Legacy
host
reaches
you
directly.
Instead
of.
J
M
An
orange
which,
what
that's
the
first
drawing
right,
the
one
where
we
we
share
the
network
you
may
or
may
not
want
to
do
that
it
just
depends
if
you
want
everyone
to
know
about
this
prefix
or
if
it's
a
prefix,
that
has
a
special
purpose
for
which
I
mean
it's.
It's
a
choice,
administrative
choice
to
do
it
or
not,
but
yes,
it's
completely.
M
So,
in
that
case,
here
I
think
I,
don't
think
it
has
to
be
globally
reachable
by
anyone.
For
instance,
if
you
have
a
power
grid,
and
you
want
that
stuff
to
for
for
the
power
related
messages
to
go
out
the
power
lines
actually,
but
for
anything
else
to
go
out.
We
have
use
cases
like
that
in
iot,
so
you
you
want
you.
M
Know
that
prefix
only
the
you're,
washing
machines
and
stuff
these
are
still
connected,
so
the
Wi-Fi,
the
the
build
on
that
prefix
is
they
do
power
related
stuff?
They
go
out
one
way
if
they
do
something
else,
they
go
out.
The
other
way
I
mean
we
want
to
have
all
the
power
to
play
with
things.
Okay,.
G
Mean
Michael
Richardson,
so
my
thoughts
about
this
work
and
I,
you
know
followed
it
through
six
men
and
six
low
and
stuff
like
this-
is
that
I
think
that
it
I
think
that
IT
addresses
the
edge
snack
case.
That
I
really
don't
remember
when
in
the
charter
or
not,
which
is
you
know,
the
vaguely
sort
of
industrial
uses
for
stub
networks
and
I?
Don't
think
that
really
isn't
our
chart
or
really
shouldn't
be
emphasized?
G
If
it's
there,
there
was
a
presentation,
I'm
going
to
say
two
ietfs
ago
from
in
the
iot
Ops
working
group
about
Trends
in
industrial
networks.
Right,
and
so
you
know,
he
presented
these
industrial
networks
as
if
it
was
a
virtue,
the
fact
that
they
had
layers
and
layers
of
firewalls
and
and
what
that's.
G
G
But
it's
a
very
nice
presentation,
a
very
nice
concept
right,
but
the
the
key
thing
here
that
I
took
back
is
that
it
was
very
hard
for
any
new
vendor
to
enter
an
industrial
Network
because
of
all
of
the
other
stuff.
Nobody
wants
to
reconfigure
their
Network
for
the
new
guy,
because
if
anything
goes
wrong,
it's
the
new
guy's
fault
and
they're
in
trouble
for
having
cooperated
with
the
new
vendor
right.
Well,.
M
G
Exactly
right,
so
this
is
exactly
what's
happening.
So
what
I'm
saying
is
this?
The
snack
stub
Network
actually
has
the
nice
feature
that
it?
It
actually
does
let
people
deploy
permissionlessly
into
that
kind
of
network,
okay,
and
so
the
interesting
thing
for
me
for
your
work
and
I'm.
Sorry,
if
that
was
a
little
bit
like
tenuous
and
I,
could
write
it
down
the
interesting
thing.
G
You're
not
this
concept
is
that
when
that
vendor
shows
up
with
the
second
subsystem,
because
it's
another
part
of
the
plant,
you
know
got
a
good
got,
a
good
deal
got
a.
It
was
working
well,
the
the
chemical
mixer
for
the
paint
factory
right
thing,
and
now
they
want
to
install
it
three
more
times.
Okay.
G
Well
now
they
say:
whoa
whoa
hang
on.
We
don't
need
a
whole
new
subnet.
We
can
now.
You
do
do
Eros
and
this
other
stuff,
and
we
can
actually
now
build
the
the
proxy
to
ND
kind
of
concept
across
the
whole
thing
and
I
think
that's
very,
very
useful,
but
it
requires
them
to
think
about
this
in
advance
and
I.
G
Think
the
thing
about
about,
unfortunately,
about
this
work
is
that
it's
10
years
too
late
to
go
into
thread
or
something
else,
and
so
we
really
need
all
of
we
to
do
this
usefully
we
really
needed
to
have
put
it
in
to
all
the
other
specs
that
we're
doing
something
like
specifically
thread
and
so
I.
Don't
see
thread
changing
to
be
able
to
accommodate
this,
and
that's
why
I'm
like
well,
I
really
want
to
do
it,
but
I
I.
G
G
Okay,
sure
I'm
not
saying
I
couldn't
do
it
I'm
just
saying
that
it's
not
in
the
spec
today
and
and-
and
this
is
unfortunate
and
it's
an
unfortunate
problem
of
we
don't
always
get
people
to
you
know,
especially
when
people
spin
off
and
go
elsewhere
and
do
their
work
elsewhere.
We
don't
always
get
manage
to
review
and
say
well,
but
you
could
have
just
done
it
this
way.
It
would
have
been
simpler
right
and
that's
the
problem.
G
F
Ted
lemon
just
two
things:
one,
the
use
case
for
injecting
routes
is
actually
when
you're
trying
to
work
with
a
cooperating
infrastructure
with,
and
you
want
to
be
able
to
have
the
stub
Network
hosts
be
reachable
from
non-adjacent
infrastructure
links.
So
it's
not
really
about
access
control.
It's
about
it's
about
situations
where
you
can't
get
an
RA
to
the
thing
that
needs
to
connect
to
you,
because
it's
on
a
different
link,
yeah.
So.
F
Everything
is
on
the
different
links,
right,
you're,
correct
I
mean
yeah
yeah
so
and
the
other
thing
is
I
mean
I
wouldn't
lose
hope
that
there
isn't
an
application
for
any
of
the
stuff
that
you've
done
in
thread,
because
there
were
some
things
in
there
that
I
thought.
Oh,
we
should
talk
about
that
and
thread
and
see
whether
we
can
do
it
I'm
not
saying
that
it's
going
to
get
adopted,
I'm
just
saying
I
think
it's
worth
talking
about.
F
L
B
C
A
Okay,
next
topic
of
the
agenda
is
a
discussion
where
we're
going
and
next
steps
am
I
right.
Pascal
saying
that
our
understanding,
as
you
said,
is
that
what
you're
describing
the
prefix
registration
is
actually
a
possible
tool
to
be
considered
for
snack.
But
it's
not
you
know
a
complete
solution
right.
It's
just
that,
okay,
so
I
guess
the
question
to
the
group
is:
do
we
want
to
have
do
we
want?
A
H
A
A
J
Lorenza
I
mean
do
we
have
to
do
that
like
they
seem
to
be
like
pretty
solid
agreement
within
this
room
that,
like
we
want
to
make
PD
parts
of
the
spec
I
think
we
can
just
say
that
in
the
email
it's
like,
you
know
the
chairs,
you
know
we're
calling
for
adoption
by.
You
know.
We
recognize
that
that
during
the
discussions
there
was
strong
support
for
including
PD
as
part
of
the
base
back.
Let's
assume
that
we
can
do
that
when
the
while
the
document
is
being
worked
on
yeah.
J
D
Hi
I'm
Bob
Hinton
I
was
just
going
to
say
that
adoption
usually
means
that
the
working
group
wants
to
work
on
it.
It
doesn't
mean
there's
any
agreement
or
final
agreement
on
what's
in
the
document
that
happens
later
and
that
gets
sorted
out
when
you
do
a
working
group
last
call
so
I
I
don't
see
why
we
need
to
add
another
step
here.
A
A
A
A
A
D
A
As
Eric
was
saying,
whatever
we
you
know
discuss
here
will
be
you
know
doing
this
on
the
mailing
list
and
obviously
we'll
wait.
Another
rev
of
the
document,
which
contains
at
least
one
liner
to
formally
call
the
the
adoption.
But
you
know
this
you
know,
gives
us
a
good
feel
for
the
working
group
chairs.
A
K
Remember
what
we're
discussing
right
now
and
those
I've
rarely
seen
such
a
clear
consensus?
What
we're
discussing
is
whether
the
working
group
is
going
to
work
on
this
document
once
the
working
group
products
that
adopts
the
document
is
up
to
the
working
group
to
determine
what
goes
into
that
document.
Right,
we're
not
saying
the
document
is
finished
and
ready
for
last
fall.
We're
saying
this
is
an
interesting
area
to
work
on.
A
A
D
F
So,
just
to
clarify
the
second
deliverable
deliverable
is
the
case
where
we
want
to
have
additional
functionality
that
is
enabled
by
integrating
with
the
infrastructure
Network
and
what
that
would
mean
is
essentially
the
ability
to
do
discovery
of
hosts
on
the
on
the
stub
network,
from
non-adjacent
infrastructure
links
and
the
ability
to
reach
hosts
on
the
infrastructure
network
from
non-adjacent
infrastructure
links.
Since
we
just
added
DHCP
V6,
we've
sort
of
solved
that
problem.
The
second
problem,
but
we
haven't
solved
the
first.
So
that's
the
big
difference,
I
think
in
the
document.
F
M
M
M
The
phone
is
the
step
brother,
but
the
prefix
is
not
provided
by
the
httpd
and
you
have
to
to
act
as
a
relay
for
the
Wi-Fi
by
the
way,
but
I
mean
just
wondering
if
that
could
be,
because
at
home
I
would
have
used
it
recently.
If
I
had
it
because
I
had
this
discard,
so
they
cut,
they
cut
my
fiber
literally
on
the
road
right.
Road
work
got
fiber
and,
and
my
whole
home
was
isolated,
but
I
had
my
phone
and
I
I
could
effectively
teaser
a
few
things
on
my
phone.
M
M
M
F
So
Ted
lemon
I
what
Pascal
just
described
as
a
use
case
that
sort
of
fell
into
the
home
net
Charter
but
doesn't
entirely
fall
into
our
Charter
and
there's
a
reason
why
we
constrained
our
Charter
the
way
we
did
it's,
because
we
want
to
get
something
done
that
actually
works
and
that's
not
to
criticize
what
Pascal
is
proposing,
because
I
think
what
Pascal
is
proposing
is
also
useful.
But
we
probably
ought
to
get
the
work
done
that
we're
chartered
for
first
and
then
we
can
see
if
we.
A
J
Lorenza
clivia
I
think
that's
out
of
scope,
but
also
I
mean
this
is
not
so
it
doesn't
need
any
protocols
to
do
this.
Right,
like
all
you
need,
is
an
option
on
your
phone.
That
says
become
a
router
for
the
for
the
Wi-Fi
network
and
that's
it
right.
I
mean
I
I,
don't
think
the
mobile
devices
on
the
market
today
have
this
option.
G
Michael
Richardson
here
so
I
think
it
largely
Works,
actually
Lorenzo
I
actually
think
I
just
have
that
option,
but
it
just
it
just
doesn't
work
with
every
every
LTE
provider
that
provides
V6
for
some
reason.
Some
of
them
don't
do
the
right
thing
to
enable
tethering
and
I
haven't
figured
out
the
pattern,
but
I
know
it
worked
in
Austria
and
Netherlands,
but
not
in
Germany
on
the
same
sim.
G
G
Increasingly,
we
have
people
that
don't
have
internet
connections
at
home
and
they're,
okay,
with
the
concept
that
their
home
is
offline
when
their
phone
is
not
present
right
and
so
that's
kind
of
is,
is
a
you
know,
I
think
we
should
think
about
the
stub
Network
situation.
In
that
scenario,
where
there
was
a
15.4
Network
behind
a
stub
router
in
the
coffin
hotel
right,
my
phone
shows
up
as
the
CPE
router
I.
Don't
think,
there's
any
any
changes.
G
E
L
Yeah,
so
it
just
got
me
thinking
about
Cellular
in
home,
so
there's
one
case
that
is
getting
increasingly
common
is
to
have
cellular
backup
of
your
home
router.
So,
instead
of
having
only
a
cable
or
Fiber
connection,
you
also
have
a
an
additional
cellular
backup.
So
we
might
have
to
consider
that
kind
of
case
what,
if
the
yeah
home
router
slash
CPE
switches
to
the
cellular
backup,
so
would
that
have
any
impact
on
the
connectivity?
L
We
of
course
want
to
keep
that
connectivity
for,
for
all
the
iot
devices
or
stop
network
devices
that
there
are
so
I
think
that's
something
to
consider
as
well,
not
just
a
user
phone
that
takes
that
function,
but
an
actual
backup
module
in
the
CPE.
Maybe
there's
nothing
special.
We
need
to
do
for
that.
A
L
M
I'm,
sorry,
if
that
that's
not
the
chatter,
for
the
point,
I
mean
I
wanted
more
than
the
array.
What
what
I
was
asking
is
probably
that
the
devices
don't
effectively
change
their
addresses.
They
want
either
to
my
phone
stated
or
to
my
phone.
They
see
I
need
the
phone
prefix,
the
one
or
they
know
the
phone
prefix,
the
one
that
are
on
my
home,
keep
the
home
address.
M
J
M
J
You
can't
have
you
can't
just
have
devices
on
the
home
network
forward
to
the
Gateway
and
the
Gateway
forward
to
the
phone,
because
the
source
address
will
be
wrong.
They
will
be
using
the
Wi-Fi
network
Source
address
from
the
assigned
by
the
ISP,
which
is
now
basically
off
the
network
off
they're,
basically
disconnected
from
the
internet,
and
so
it's
just
going
to
go
nowhere.
I
mean
you
couldn't
add
it,
but
we
should
probably
not
go
there.