►
From YouTube: IETF95-INTAREA-20160405-1620
Description
INTAREA meeting session at IETF95
2016/04/05 1620
A
And
also
welcome
to
the
interior
working
group
session
here
at
when
Osiris
my
name
is
Juan
Carlos
zuniga
population
interdigital.
He
witnessed
suresh
krishna,
my
dear
culture
and
new
culture
was
in
haddad
and
we
have
three
chairs
for
this
one
time.
Sudesh
is
going
to
be
leaving
us
to
achieve
new
challenges
in
its
life
as
new
ad
soon.
B
B
Thank
you
very
much
run
Carlos,
so
I'll,
be
leaving
the
group
as
chair
and
I'll,
be
becoming
Eddie
for
the
group
in
charge
of
the
group
so
like
just
to
avoid
any
conflict
of
interest.
So
Brandon
I
decided
like
this
the
best
thing
to
do
so
what
seemed
is
taking
over
a
share.
So
thank
you
all
for
your
support
for
now,
and
please
continue
to
do
so
with
waseem
us
all.
Thanks.
C
C
B
A
Alright,
so
let's
move
on
to
the
slides
first
of
all
the
not
well,
as
you
know,
you
should
be
pretty
familiar,
but
this
is
an
ietf
official
meeting,
so
you
have
to
abide
by
the
rules
of
ITF.
So
please
take
note
of
the
submissions
and
rules
and
all
material
and
participation
czar
according
to
IETF
rules.
A
So
reminder
we
are
going
to
be
taking
minutes.
The
meeting
is
being
recorded,
your
presence
is
locked
and
we
ask
please
describes
to
contribute
online
as
much
as
possible
minutes
at
the
etherpad.
Their
recordings
and
minutes
are
public
and
may
be
subject
to
discovery
in
the
event
of
litigations
and
of
course,
please
make
sure
you
sign
the
blue
sheets,
so
blue
sheets
are
going
around.
We
have
a
note
taker
and
jabber
scribe
right,
Ian
and
Michael
are
helping
us
with
that.
So
thank
you
very
much
for
that,
and
this
is
agenda
that
we're
bashing.
A
So
we're
going
to
start
by
giving
you
some
status
on
on
documents
that
we
have
the
working
group
documents
and
then
we
are
going
to
move
on
to
the
presentations
on
ad
hoc
wireless
networks
by
Charlie
multicast.
We
have
a
little
more
time
there
to
discuss
that
one.
The
IP
broadcast
consideration
from
Rolfe
I,
p,
/,
partially
partitioned
links
from
Eric
in
nineteen
UDP
from
yahoo.
A
There
are
none,
then
status
update
so
for
the
draft
IETF
interior
tunnels.
We
don't
have
a
presentation
this
time,
there's
a
current
list
of
pending
issues
that
the
authors
have
acknowledged,
and
this
is
not
an
inclusive
list,
but
it
it
also
touches
on
augmenting
the
text,
the
additional
notes
that
they
want
to
add.
Diagnostics
terminology
pseudo
code
updates,
dame
tu
topic,
the
multipoint
tunnels,
Heather
translations,
relation
to
existing
RFC's
and
general
clarifications.
A
C
Wait
a
minute
dev
and
I
prepared
this
document
in
a
bog
meeting,
and
then
we
add
an
electron
call
and
Bill
told
us
to
you:
yeah
go
for
it,
so
we
published
the
draft
as
an
internet
draft
back
in
October
and
we
did
not
have
a
whole
lot
of
feedback.
I
I
can
take
an
addicting
pass
at
it,
but
basic
the
dwarf
is
obvious
good
as
it
will
get
and
that's
the
absence
of
more
feedback.
Okay,.
G
C
We
have
to
know
what
we
want
to
do
right
now.
We
shall
read
them,
I.
Think
it's
a
real
problem.
We
have
started
to
work
on
that
problem
in
the
DNS
SD
working
group
as
well,
but
I
mean
it's
maulin,
dns
SD.
There
are
the
issues
with
a
basic
usage
of
names
in
different
contexts,
mdns
application.
So
I
think
that
the
draft
mean
feel
the
need
and
we
need
to
have
some
progression
down
lately.
F
F
F
A
So
the
the
document
actually
got
adopted,
it
got
what
a
good
support
in
brag,
but
so
what
we're
missing
at
this
point
is
reviewers.
So
is
anybody
willing
to
to
to
take
a
look
at
the
document
and
Cynder
review?
I.
Think
that'll
be
helpful
for
the
authors
and
for
us
as
working
group
church
to
to
know
how
to
proceed.
A
Okay,
that's
not
a
lot,
so
we
do
need
more
people
to
take
a
look
again
as
well
set
the
we
believe
it
it's
a
real
problem
and
then
we
believe
the
document
is
racing
with
points
and
proposal,
good
things.
So
so,
please
take
a
look.
We
need
feedback
before
progressing
with
these
documents,
so
I
encourage
people
to
to
take
a
look
and
send
comments
on
the
list.
Especial
right,
ok,
so
moving
on
the
next
draft
is
ITF
interior,
ad
hoc
wireless
Charlie
and.
I
How's
it
okay,
that's
good,
how
we
even
have
a
monitor
your
dishes-
fabulous,
okay,
well
anyway,
so
this
was
intended
to
be
just
a
very
short
update
to
the
draft
we
have.
This
draft
has
been
around
for
a
good
while
it
was
adopted
as
an
interior
draft
last
year,
and
we
did
make
an
update
to
it.
It
was
discussed
about
previous
to
RFC
called
pilk
performance
implications
over
there,
two
considerations
or
something.
I
That
was
a
very
interesting
in
a
long
draft,
but
this
actually
doesn't
try
to
redo
any
of
the
work
from
pilk.
It's
really
motivated
by
what
we
had
a
lot
of
discussion
in
the
mobile
ad
hoc
network
group
and
it
seemed
it,
and
it
was
not
really
a
lot
of
understanding,
especially
in
a
group
called
auto
conch
about
the
things
that
really
go
on
for
multi-hop
ad
hoc
networks.
I
So
so,
just
briefly,
the
graph
talks
about
asymmetry
and
Tom
variance
and
the
fact
that
if,
for
instance,
up
there,
a
is
a
neighbor
to
B
and
C
its
neighbor
to
a
and
D
is
a
neighbor
to
see
doesn't
say
anything
about
whether
d
can
actually
communicate
directly
with
be
or
not
talking
to
the
mic.
Okay,
thank
you.
I
I
have
now
a
whole
Mike,
so
yes,
so
I'm
just
after
three
nodes,
a
B
and
C.
If
a
is
a
neighbor
to
B
and
C
is
a
neighbor
to
a
then
it
doesn't
necessarily
it
all
mean
that
C
is
a
neighbor
to
to
be
in
de
nirsa.
Not
it
not
a
will
to
find
range
to
wireless
communications,
so
that
leads
to
some
difficulties
and
basically,
what
it
comes
down
to
is
that
the
concept
of
connectivity
is
not
as
crisply
defined
as
it
is,
for
instance,
for
Ethernet.
I
So
what
I
guess
the
presentation
here
somehow
isn't
like
my
powerpoint,
because
that's
supposed
to
be
ambiguous,
so
the
concept
of
a
neighbor
becomes
ambiguous
and
a
definition
of
a
link
is
no
longer
is
crisp,
and
this
has
been
the
source
of
a
lot
of
or
maybe
even
megabytes,
a
discussion
on
the
various
mailing
list.
In
particular,
if
you
want
to
define
the
subnets
in
the.
I
L
L
I
L
I
I
Okay,
thank
you.
So
this
is
a
quite
different
on
this
presentation
is
related
to
a
recently
submitted
internet-draft,
describing
first
of
all,
a
lot
of
problems
that
have
been
noticed
about
running
multicast
protocols
over
on
Tripoli
802
wireless
medium.
There
was
a
presentation
in
Yokohama
from
Dan
Arkin's
using
material
developed,
a
tight
Ripley
attitude
at
eleven
and
Dorothy
Stanley
was
instrumental
in
creating
that
material,
and
so
this
was
a
very
motivating
presentation
and
then,
when
we
met
again
it
I
Triple
E
wireless
meeting.
I
After
that,
we
got
together
just
to
create
a
full
document,
armina
more
complete
document,
444
IETF,
because
these
are
really
important
matters,
and
it
makes
a
lot
of
difference
so
on
next
slide.
Please!
So,
basically,
a
lot
of
problem
is
simply
I.
Guess
you
would
say
physics
the
way
multicast
works.
I
That
means
you
actually
occupied
a
medium
for
a
longer
time
and
the
higher
power
means
that
you
not
only
occupied
for
a
longer
time,
but
the
range
of
interference
can
be
much
much
larger.
In
fact,
one
case,
it's
aside
it
in
in
the
draft
and
in
the
presentation
for
November
ITF.
There
is
a
factor
of
a
hundred
difference
in
mean
you
can
imagine
multicast
going
at
six
megabits
per
second,
whereas
the
unicast
goes
at
six
six
hundred
megabytes
per
second,
and
I
don't
think
that
ders
oh
I
mean
that's
just
an
example.
I
It
can
be
better
or
worse
than
that.
So
that's
that's
really
a
major
consideration.
The
other
thing
is
that
in
some
ways
edict
11
has
been
optimized
for
unicast,
and
that
means
that
using
modern
equipment
pretty
much
the
packet
will
get
there
and
if
not,
you
can
acknowledge
it
or
even
more.
You
can
add
acknowledgement.
Wouldn't
common.
You
can
retransmit,
but
you
know
Cass
spoil
it
ends
up
being
much
much
more
reliable
than
multicast
and
it's
not
unusual
to
see
fifteen
or
twenty
percent
a
loss
for
multicast
delivery.
I
I
The
interference
range,
as
mentioned
before,
is
irregular
and
time-varying,
and
that
means
it's
a
more
difficult
to
plan
how
to
mitigate
these
effects.
And,
lastly,
because
of
the
way
a
tour
2011
works.
If
you
have
an
access
point
in
it
at
serving
a
collection
of
customers
or
stations,
then
that
can
be
bridged
into
the
hard
land
and
all
the
problems
that
are
coming
from
the
wireless
segment
of
the
of
the
land
affect
the
wired
segment.
Two
next
slide,
please
so.
I
I
I
I
So,
as
a
result,
some
multicast
protocols
had
really
been
disabled
on
the
Wi-Fi
and
then
I
want
to
specifically
mention
Warren
Kumari
sent
us
a
lot
of
text
after
we
had
met
it
I
triple
a
meeting
last
year,
and
so
and
there
was
a
lot
of
interesting
discussion
about
the
effects
of
fun
people
trying
to
well
I,
guess
you're
you're
scanning
to
find
out
all
the
information
they
can
about
who's
using
Wi-Fi
and
who's.
Not
so
I'll
describe
more
about
that
later.
So
taking
a
material
from
the
November
interior
presentation.
L
I
And
then,
after
that,
I'll
talk
about
what
can
be
done
to
mitigate
the
problems
from
the
spurious
neighbor
discovery.
Excellent,
so
proxy
arp
is
a
good
idea
as
specified
in
this
document.
Form
80,
2011,
2012
and
50.
Ap
means
access
point
in
SD
a
stands
for
station
and
this
is
our
tripoli
terminology
for
access
point
and
a
wireless
device.
So
since
the
access
point
is
really
the
connectivity
manager
for
on
the
wireless
devices,
it
has
information
about
the
MAC
addresses
and
all
that
sort
of
thing.
M
L
I
There's
a
facility
for
power
say
where
you
can
essentially
go
to
sleep
for
a
while
and
wake
up,
or
you
want
small
and
see
if
you've
got
packets
that
are
going
to
be
delivered,
but
for
milk,
so
in
the
AP
can
improve
that
by
actually
buffering
packets.
So
it
doesn't
have
to
send
them
out
exactly
when
the
device
doesn't
want
to
send
it
out
when
the
device
is
asleep.
So
there's
this
buffering
feature,
but
that
doesn't
really
work
very
well
for
multicast.
I
L
I
N
Last
line
not
currently
implemented
in
products,
I
think
the
standard
through
religious
figure,
dream
I'll,
sorry,
Andrew,
McGregor,
google.
I
think
the
standard
version
of
this
is
not
widely
implemented,
but
this
technique
is
still
used.
There
are,
I
know,
of
a
couple
of
list
of
products
that
do
this
anyway,
despite
the
standard.
Okay,.
I
I
G
Yeah,
just
Michael
Abrahamson,
yet
so
in
response
to
that
is,
they
might
be
it.
There
seems
to
be
two
two
classes
of
products.
At
least
one
is
like
consumer
Wi-Fi
access
point,
and
one
is
enterprise
and
the
the
number
of
functionality
in
each
is
vastly
different.
So
when
this
is
not
widely
available
in
residential
products,
I
guess
yeah.
So.
A
If
I
may
interject
here
as
a
go
off
for
now,
it
indeed
I
think
that's
one
of
the
issues
that
we
are
looking
to
improving
in
the
in
the
document
to
specify
what
is
actually
implemented.
Besides
that
the
standards
view
they
issues
the
current
solutions
that
what
your
point
is
is
very
valid
right
now,
there's
two
very
different
implementations
from
the
residential
and
the
NBA
enterprise
arena.
So
so
it's
worth
documenting
those
so
that
people
understand
whenever
they
experience
issues.
What
exactly
is
that
the
type
of
appointment
that
they
are
working
on
thanks.
H
Not
only
slick
with
Huawei
is
a
good
thing
when
you're
doing
very
high
bandwidth
transmissions
without
11,
so
you're
doing
a
lot
of
aggregation.
The
amount
of
time
it
takes
to
seize
the
air
channel
becomes
a
larger
and
larger
down
a
thing
so
that,
if
you
have
a
model,
a
small
number
of
stations,
it's
vastly
more
efficient
to
who
include
copies
of
multicast
traffic
in
the
unicast
aggregations
being
sent
without
the
unicast
traffic
to
each
of
the
stations
and
many
higher-end
access
points.
H
I
That
brings
up
something
in
case
I
forget:
there's
a
draft
about
a
meal,
mitigating
problem,
food
multicast
with
MLD
normal,
and
so
that
text
needs
to
go
in
this
draft.
But
it's
not
there
yet.
So
that's
relevant
to
what
you
said
so
I
think
I
sit
for
that
slide.
Next
slide,
please
and
then
the
last
thing
is
the
problem
I
mentioned
before,
whereby
unicast
traffic
can
be
acknowledged
and
retransmitted
if
necessary,
but
multicast
is
not
well.
I
G
Yeah
Michael
abrahamson
again
I
think
this
was
also
this
is
this
is
a
function
that
is
needed
both
on
the
station
and
or
the
AP
right.
So
it
might
be
good
if
you
could,
when
you're
writing
that
text
we
were
talking
about
that.
You
include
this
is
an
AP
function,
ap
only
function,
and
this
here
is
something
that
the
stations
and
the
AP
needs
to
implement
for
that
or
work.
I
think
whether.
L
G
I
I
L
I
Multicast
for
control,
traffic
or
control
signaling
should
be
thought
of
bed
very
carefully.
So
even
if
it
does
work,
it
could
be
that
input
using
this
technique.
This
causes
too
much
latency
for
some
sorts
of
application
flows,
because
you
can
see
the
steps
that
you
have
to
send
out
the
request
for
acknowledgement
and
then
wait
for
the
acknowledgement
to
come
back
and
then
retransmitted
any
miss
frames
and,
and
then
then,
after
that
you
can
start
delivering
whatever
frame
came
after
the
multicast.
So
so
anyway,
this
has,
you
might
say,
logistical
problems
as
well.
Next
slide.
I
So
in
a
few
more
minutes
talking
about
this
problem
with
spurious
neighbor
discovery
spurious
in
the
sense
that
someone
out
there
is
trying
to
maliciously
discover
things
about
the
network
that
they
I
mean
that
they
don't
really
need
to
know.
So
the
problem
is
severe,
though,
because
they've
here
at
ITF,
measured
on
the
spurious
up
attacks
2000
broadcast
per
second-
and
that's
really,
not
very
nice.
So
some
of
the
techniques
that
have
been.
I
I
L
I
You
can
just
not
allow
any
requests
for
mac
addresses
outside
that
range.
You
can
disable
our
up
entirely,
because
maybe
you
don't
really
need
it,
since
the
aprt
has
all
that
information
and
it's
the
router
in
Sims
some
implementations,
so
it
shouldn't
be
need
for
the
ARP
request
at
all.
For
that
then
there's
two
others
ones
called
Matt
so
but
nobody
likes
an
ad
and
the
other
one
it
just
to
not
let
any
unsolicited
incoming
traffic
come
in.
I
K
Yes,
Eric
Eric,
not
Mike,
so
there's
another
one
that
has
been
discussed
over
the
years
and
six
men
witches
and
the
efficient
and
D
draft,
which
is
having
some
form
of
address
registration
rights.
Where
were
the
hosts,
would
actually
register
of
our
ipv6
address
with
some
entity
in
the
network.
And
if
you
do
that,
you
actually
it's
similar
to
the
the
AP
already
having
the
ARP
cache
entry,
you
can
actually
maintain
that
that's
an
other
potential
venue
there's
been
concerns
around
and
making
that
type
of
mechanism
mandatory,
but
supposed
to
being
an
optimization.
Ok,.
I
Ok,
so
here
then
slide
it
wasn't
here
till
this
morning,
I
put
in
the
mailing
list.
If
you
want
to
join
in,
to
make
a
contribution
so
but
I
had
21,
you
there's
not
much
there
right
now.
Next
slide,
please,
and
so
now,
I
want
to
say
a
couple
of
things
about
a
little
bit
of
the
history
about
this,
as
I
mentioned
0.
First
of
all,
is
your
question?
I
Ok,
ok!
So,
as
I
mentioned
after
the
presentation
from
dan
hawkins
and
interior
previous
my
TF,
it
was
noticed
that
there
was
a
huge
amount
of
interest
about
this,
and
so
we
got
together
at
I,
Triple
E
and
decided
to
make
a
distract
and
in
the
meantime,
last
year
there
was
a
draft
from
Mike
Mike
McBride
is.
L
I
Here,
buddy
chance,
okay,
so
anyway,
this
was
submitted
in
disgust
and
em
buon
d
working
group,
and
they
were
they
were
also
interested,
but
that
draft
sort
of
didn't
go
anywhere,
and
then
there
was
this
interest
in
the
other
community.
So
I
would
encourage
you
to
take
a
look
at
the
in
bone
draft
as
well
and
I'm
going
to
be
presenting
this
in
the
embo
working
group,
which
I
think
is
tomorrow
morning
a
while
back.
There
was
a
draft
from
eric
mikey.
Is
it
pronounced
by
Kiger
binky?
I
I
Worthwhile
to
take
a
look
at
and
then
there's
a
charter
item
in
pin
to
submit
solutions
for
a
GMP
and
MLD
to
adapt
to
wireless
link,
conditions
and
I.
Think
the
gum
in
Bondi
meeting
tomorrow
morning
is
also
a
joint
meeting
with
him.
So
so
anyway,
I
expect
there
will
be
some
interest
on
this
side.
This
general
area
mls.
O
I
O
A
I
O
E
Ten-Chan
two
points
or
questions
first,
is
whether
you
want
to
consider
also
things
that
are
that's
what
sadly
broadcast
or
things
like
in
the
beginning
that
access
points.
Do
you
have
lots
lots
of
SS
IDs,
for
example,
the
performance
can
go
down.
Maybe
that
affects
LT
cast
as
well.
I'm,
not
sure
this
is
that
worth
considering.
E
E
I'm
just
wondering
whether,
when
you
have
a
network
with
lots,
lots
of
SS
ids
and
there's
lots
weakening
going
on,
you
could
study
as
and
show
you
how
the
performance
of
the
whole
Wi-Fi
system
fails
or
falls
deprecated.
How
is
the
word
deteriorates
sorry
got
a
bit
of
a
cold.
Is
that
something
you
want
to
be
considering
here
alongside
multicast
various
broadcasting
that
can
be
happening
as
well
as
it
related?
Do
you
think.
E
I
E
G
Michael
Abramson,
so
the
IE
injected
myself
into
this
like
half
year
ago,
or
something
because
of
the
discussions
in
home.
Letters
are
on
about
multi
cousin
and
my
goal
of
doing
that
was
to
fit
to
make
I
Triple
E
and
the
IHF
figure
out
a
joint
way
of
saying,
okay.
This
organization
tries
to
do
that
and
I'd
I
triple
it.
Does
that
because
there
was
some
finger
pointing
in
the
beginning
to
say:
I
like
don't
use
multicast,
and
why
aren't
you
suppose
supporting
multicast
and
I?
I
D
Part
of
the
IETF
lock
team,
so
I
stood
back
up
because
somebody
said
that
they'd
heard
that
some
folk
thought
this
wasn't
really
a
problem.
This
is
where
the
audience
participation
portion
of
this,
who
all
came
to
the
prog
IETF
meeting,
who
thought
the
IETF
wireless
networks
like
there,
you
can
put
your
hands
up.
Aurea
won't
be
offended.
D
Who
here
thinks
it
sucks
slightly
less
this
time?
Well,
everybody
who's
slightly
happier
is
almost
entirely
because
we
managed
to
stop
a
lot
of
the
broadcasts
we
stuck
on
wireless
LAN
controllers.
They
take
care
of
this
for
us,
and
so
any
improvement
that
you
see
is
almost
entirely
because
of
that.
Any
secretary
experience
before
was
almost
entirely
the
broadcasts.
Okay,.
I
P
You
Stewart
cheshire
Apple,
thanks
for
this
work,
I
do
think
that
understanding
of
Wi-Fi
performance
characteristics
is
important.
Tim
mentioned
the
hybrid
proxy
and
you
made
me
realize
I
there
is
that
number
in
there
without
any
justification,
but
it
was
not
actually
pulled
out
of
the
air
but
and
I'll
just
explain
for
the
benefit
of
the
room.
P
Originally
I
know
it's
changed
now,
but
Wi-Fi
used
to
default
to
one
megabit
per
second
for
multicast
I
know
now
six
is
more
typical
and
a
full
size
frame
is
about
ten
thousand
bits
that
one
megabit
per
second.
That
means
a
hundred
multicasts
per
second
is
one
hundred
percent
of
your
spectrum,
so
I
pics
20
as
being
ballpark.
P
E
Like
if
you
can
matter
point
quick
pay
attention
to
spring
creek
point,
so
that
does
remind
me
what's
one
of
these
you
could
mention.
The
document
is
if
you're
running
v6
only
you
have
an
advantage
that
you're
not
doing
a
v4
and
v6
bonds.
You
a
message
is
modular,
typically
ask
the
same
question
over
both
protocols.
M
Guardian,
on
general,
we
see
so
yeah.
Thanks
for
this.
This
presentation
I've
heard
some
actually
pretty
compelling
argument,
saying
you
know
just
give
up
on
multi
cousin
wireless
and
solve
with
that
the
issue
layer,
that's
a
viable
alternative.
I
think
it's
worth
at
least
document
to
the
issues.
What
efforts
are
going
on.
Maybe
there's
definitely
improvement
that
that
can
be
done
and
talk
about
those
I
didn't
notice
in
your
list.
We
have
a
document
in
six
low
recently
adopted
could
be
applied
to
dot11
as
well
backbone
router.
M
So
Pascal
has
been
working
on
that
for
34
years.
There's
some
implementations
that
so
that's
another
one.
You
might
want
to
think
about.
It's
reminiscent
of
the
ATM
Mars
solution.
You
have
a
unicast
type
solution
out
of
some
other
node
in
the
network.
I
also
was
wondering
about
the
power
safe
solution
which
you
have
buffering
and
if
you
have
buffering,
then
you
might
have
a
buffalo
problem.
I
know:
there's
been
presentations
in
I
Tripoli
about
precisely
buffer
glowed
and
using
kodel
or
fq
hefty
cuddle
or
whatever
I,
don't
know
where
those
have
gone.
M
I
A
Well,
please
bring
those
points
to
the
list
that
we
actually
have
set
up
a
specific
mailing
list,
because
we
believe
there's
a
lot
of
things
that
we
should
cover
and
we
don't
want
you,
you
know
hijack
the
interior
mailing
list.
So
if
you
don't
mind,
I
think
that'll
be
very
useful
information
and-
and
we
can
keep
going
we're
far
from
being
done
with
this
document.
So
all
feedback
you
can
bring
would
be
very
helpful.
Thank
you
much
row.
Alright,.
F
So
this
ought
about
broadcast
and
multicast,
but
it's
about
privacy
considerations
next
slide.
So
this
not
this
work
is.
We
did
experiments
on
a
campus
network
with
over
5,000
users,
and
we
also
did
the
same
experiment
during
the
last
ITF
meeting
on
the
oklahoma
network,
where
there
were
also
no
broadcast
messages,
which
kind
of
was
bad
for
our
experiment.
F
But
we
did
their
visit
permit
for
a
24-hour
period
over
on
two
of
the
SSID
s
next
slide
so
broadcast
America
is
special
from
a
confirm
from
a
privacy
perspective,
because
very
often
that
is
the
only
method
to
implement
something
efficiently.
For
example,
local
service
discovery
auto
configuration,
so
you
need
to
resort
to
it
and
it
turns
out
a
lot
of
money.
F
So
these
are
the
observation
from
this
experiment.
Some
apps-
and
these
are
not
typically
ITF
specified
protocol.
Some
apps
they
broadcast
very
frequently,
and
so
your
online
times
are
observable.
It's
an
on-location
because
on
the
land
and
it's
a
couple
of
broadcast
per
minute
per
app,
so
that
adds
up
when
you're
five
thousand
users
on
the
on
the
network
and
just
not
the
efficiency
parties,
also
the
privacy
part
so
he's
an
example.
One
pocket
very
popular
app
observed
account
for
seven
percent
of
all
the
broadcast
traffic
on
that
particular
network.
F
A
lot
of
those
apps
use
persistent
identifiers,
and
they
are
not
it's
like
a
uuid
or
something-
and
these
identify
us,
for
example,
identify
the
installation
of
a
certain
application,
so
certain
application,
or
that
particular
installation
broadcast
an
identifier
and
that
isn't
particularly
bad,
because
this
will
destroy
efforts
on
lower
layers
so
make
address.
Randomization
IP
address
randomization
is
completely
useless.
F
If
you
see
an
IP
address
and
then
purchase
an
identifier,
so
you
have
anywhere
you
have
a
new
mac
address,
we've
no
a
dress,
but
you
have
a
persistent
identifiers
that
never
changes
in
those
broadcast
messages.
So
anything
you
do
below
in
terms
of
anonymization
and
it's
completely
broken
at
that
point
in
time.
Next
slide.
Some
protocols
bury
a
carry
user-specific
specified
data
such
as
host
names
and
there's
a
draft
about
this
and
here's
some
data
from
the
ITF
experiment.
F
So
there
were
no
broadcast
on
that
on
that
Network,
so
the
numbers
are
real
0
plus
we
had
to
anonymize
the
data
for
so
in
Yokohama
I
learned
later
on,
we
wouldn't
have
needed
to
analyze
the
data
in
Germany.
There
was
a
big
deal
and
the
legal
team
that
actually
dealt
with
this.
They
wrote
a
paper
about
the
legal
aspects
of
all
this.
There
was
very
interesting
so
out
of
the
2600
devices
I'm
on
the
anonymized
data.
F
We
could
identify
the
owner
of
240
of
those
devices
uniquely,
so
we
could
say
this
device
is
owned
by
a
certain
person,
and
we
could
do
that
because
the
we
anonymize
the
data
we
throw
away
the
key,
but
before
we
threw
away
the
key,
we
anonymized
use
the
same
method
on
the
attendees
list,
and
so
we
just
matched.
How
can
so?
F
We
could
say,
okay,
this
person,
that
has
a
last
name
as
unique
and
we
found
the
same
token
in
our
data,
and
so
we
could
say
at
least
one
of
40
of
those
devices
we
could
identify
the
owner.
We
could
renew
this
person
owns
the
device,
we
did
control
experiments
with
students
and
there
was
much
more
data
in
there.
So
if
you
don't
have
to
naanum
eyes
and
attack,
it
usually
doesn't
do
that.
You
have
much
more
information
to
work
with
next
slide
and
you
have
a
lot
of
protocols
out
there.
F
So
it's
not
just
one
protocol
and
and
one
on
itself
looks
secure
and
it
doesn't
reveal
a
lot
of
information.
But
when
you
correlate
a
lot
of
these
protocols,
then
you
could
we
were
able
to
build
a
social
graph
of
the
person,
so
we
could
say
just
by
looking
at
the
broadcast
data.
This
person
is
sharing
data
with
another
person
and
when
you
have
the
name,
we
identified
the
person
that
entity
we
could
identify
other
people
and
we
knew
they
exchange
data
with
each
other.
F
Just
by
looking
rod
cast
so
correlation
is
a
big
advantage
next
for
an
attack,
at
least
next
slide,
and
we
looked
at
some
of
the
applications
that
actually
implement
these
protocols
and
it
turns
out,
none
of
them
are
really
configurable,
so
it
on/off
is
the
most
we
saw,
but
typically
want
to
have
something
where
you
can
say.
Okay,
I
want
to
do
this
at
home,
so
maybe
configure
this
for
a
particular
SSID,
but
none
of
the
applications
we
looked
at
we're
able
to
get.
F
You
could
switch
that
feature
I
enough
for
some,
but
you
couldn't
configure
them
really
next
slide.
So
why
does
this
matter
so
far?
A
lot
of
the
protocols
that
the
ITF
is
developing?
That's
already
ongoing
work,
this
DNS
SD,
we
heard
there
was
a
DHCP,
but
those
aren't
that
relevant.
We
think
because
we
know
these
protocols
and
a
lot
of
products
they
have
something
built
in
that
helps
with
the
privacy
I'm
parts
as
well
like
DHCP
snooping,
for
example,
you
don't
have
to
rebroadcast
a
DHCP
and
product
support
this.
F
So
this
is,
you
won't
see
the
request.
You
won't
see
the
broadcast
as
a
regular
user
of
the
network.
You
also
have
the
the
working
groups
that
deal
with
privacy
issues.
You
have
sector
accurate
reviews
and
things
like
that,
but
the
protocols
that
app
developers
do
they
don't
have
that.
So
this
is
why
a
lot
of
them
aren't
optimal.
F
In
that
respect,
me
right,
x-lite,
that's
why
you
think
that
these
guidelines
are
interesting
for
these
people,
so
there's
a
lot
of
other
privacy
work
going
on
in
the
HF
there's
the
hostname
draft
that
we
talked
about
today.
The
IP
address
randomization
there's
some
work
among
this
mdns
DNS
SD
related
work,
dhcp
related
work,
but
we
really
target
a
different
group
of
people,
people
that
building
and
protocols
that
are
not
developed
unfortunate,
not
developed
in
the
IDF.
This
can't
be
our
focus
of
the
of
this
document.
C
Yeah
I
mean
thank
you,
for
the
data
is
very
interesting
when
I
when
I
look
at
that
this
form
of
apps
doing
the
a
doc
multicast
things
they
are
typically
doing
discovery
and
basically
they're
trying
to
like
who
can
play
with
me,
or
we
can
talk
to
me
or
something
like
that,
and
ideally
would
like
them
to
use
an
ietf
develop
protocol
to
do
that.
They
can
basically
benefit
from
the
engineering
work
during
the
IDF.
F
That's
a
good
question,
but
I
don't
think
that
that
always
helps
so
a
lot
of
so
I'll
give
you
an
example.
So
there's
one
protocol
out
there,
that
is
a
broadcasting
very
frequently
an
ID
and
some
other
information,
but
an
ID.
But
then
you
get
locally
in
the
network
and
if
they
don't
change
that
ID.
That
has
nothing
to
do
with
which
protocol
they're,
using
even
if
they
use
mdns
or
a
DNS
SD
for
that.
F
The
protocol
mechanics
are
not
that
important,
but
they
need
to
be
aware
that
that
you
need
to
change
the
ID
once
in
a
while
and
then
need
to
do
that
at
the
same
point
in
time
when
the
IETF
decides
to
also
change
and
the
idea
of
protocols
or
iOS
developers
decide
to
change
to
make
a
dress
and
change
the
IP
address.
That
is
what
they
need
to
know:
change
the
ID
and
change
it
when,
when
the
other
IDs
are
changing
as
well,
yeah.
F
K
Just
two
slides
unless
those
questions
so
I
talked
about
this
draft
at
the
last
IDF.
There
were
a
few
comments
and
there
was
one
comment
that
came
last
week
as
well.
So
I've
done
one
update
to
this
document,
which
is
to
the
first
one
when
they
fail
I
brought
up
about
reference
to
the
proxy
ND
RFC,
so
I
added
some
text
about
this
stuff.
K
We
don't
actually
need
it,
and
and
because
in
these
networks,
when
there's
multiple
routers
the
proxy
anything
sort
of
assumes
that
I
her
nourish
them
an
uplink
and
downlink
any
you
don't
actually
have
that
in
these
typologies,
you
can't
say
sort
of
avoid
loops
using
the
mechanisms
that
are
in
that
draft.
But
main
thing
is
that
it's
not
needed,
but
the
reference
is
there.
K
It
was
a
common
thing.
Is
there
place
to
put
something
about
Mac
learning,
timers
and
our
Pandey
timers
in
this
document?
I
think
I
responded
to
the
email
saying
well,
it
doesn't
quite
fit,
but
many
it's
possible
to
find
a
place
they've
fitted
in
there.
So
just
pointing
this
out.
It
might
not
be
unique
to
these
particular
sort
of
private
VLAN
and
similar
networks,
but
it's
probably
useful
to
flag
us
here's.
K
Another
thing
you
need
to
be
aware
of
when
you
running
ipv4
ipv6
from
these
networks,
so
I'll
go
look
at
a
place
where
I
can
put
some
text
in
and
there
was
a
common
on
the
mailing
list
last
week.
Those
actually
has
two
pieces.
One
is
need
to
look
at
DHCP
and
whether
dtp
also
makes
assumptions
that
the
sort
of
network
that
the
subnet
is
fully
connected
and
hence
make
might
need
some
extra
configuration,
and
this
as
well
as
I
simpiy,
redirect
at
least
for
b61
needs
to
make
sure
that
we're
not
doing.
K
I
see
I
simpiy
redirects
for
these.
These
networks,
like
p
VLAN
and
whatever,
and
those
are
things
I
plan
to
do
in
version
four,
so
I
don't
know
if
there's
any
other
question
is
a
comment
so
that
people
have
read
the
updates
to
this
document,
but
we
could
do
that
here
now
or
sounds
like
on
the
mailing
list,
since
we're
short.
A
A
I
think
yeah
we've
discussed
in
the
past
and
probably
the
mailing
list
is
the
best
place
to
continue
the
work
specially
we're
running
out
of
time
yeah.
But
yes,
please
take
a
look
at
the
document
because,
after
those
updates
chances
are
we're
going
to
be
starting
for
a
cool
column
of
adoption.
Thank
you
very
much.
Q
Everyone
I'm
Joe,
who
don't
worry
this
job,
is
about
how
to
encapsulate
IP
traffic
over
UDP
tunnels,
so
I
to
improve
blood,
balancing
efficiency
and
next
slide.
Please
RFC
564
their
Road
scribe
a
method
for
improving
a
lot
balancing
efficiency
in
a
network
carrying
software
services,
/
LTP
with
3
0,
gie
tunnels.
The
approach
describing
this
RC
require
quarters
to
do
hash
calculation
on
either
L
to
keep
ev3
session
ID
field.
All
the
GRE
k
field.
Q
The
destination
point
is
that
we're
willing
to
indicate
the
UDP
payload
is
IP
packet.
The
checksum
you
say:
follow
the
existing
UDP
related
specifications.
Next
slide,
please,
as
specified
in
RFC
5404
ip-based
traffic
is
generally
assumed
to
be
injection
control
there
for
any
tunnel
carrying
ip-based
traffic
do
not
need
additional
congestion
control,
magnets
IPO,
UTP
tunnels
in
only
you
to
carry
IP
traffic
hums
there
no
need
for
additional
congestion
control
magnum
for
IPO
UDP
tunnels.
Next,
like
this,
there
have
been
many
Upsy
and
abscess
and
working
with
dropped.
Follow
this
special
usage
of
beauty.
Q
K
Christian,
so
I
don't
have
any
problem
with
having
yet
another
flavor
of
encapsulation,
but
there's
several
pieces
of
work
that
has
been
done
for
previous
encapsulations
one
as
there's
an
RFC
50
or
there's
a
draft
called
fifty
four
or
five
bits,
which
is
about
UDP
usage
guidelines
that
talks
about
some
of
these
things
and
sort
of
the
wording
to
have
around
congestion
control.
I,
don't
remember
if
it
also
talks
about
MTU
em
to
use
an
issue
that
you
would
need
to
mention
and
say:
how
do
you
ambition
doing
MTU
when
you're
the
packet
grows?
K
If
what
happens
if
it
doesn't
fit
right
into
fragment,
what
do
you
do?
That's
one
draft!
The
other
draft
is
there's
an
encapsulation
considerations
document
that
a
design
team
did
that's
in
the
rotting
area
working
group
and
it
brings
out
other
issues
that,
like
you
probably
don't
want
to
do.
16
bits
of
random
UDP
source
ports
because
in
some
environments,
should
stay
away
from
anything
but
the
ephemeral
warps,
meaning
that
you
should.
K
You
have
14
bits
of
randomness
you
can
put
in
there,
so
it
would
be
useful
to
free
to
go
through
those
documents
and
see
okay,
tick
check
out
the
different
things.
I
did
we
cover
this
stuff
and
there
might
be
another
piece
which
is
I
believe
in
the
MPLS
over
UDP
draft
or
David
black
went
through
and
make
sure
that
everything
in
my
congestion
control,
you
know,
dotted
the
I's
and
cross
the
t's.