►
From YouTube: IETF108-INTAREA-20200727-1300
Description
INTAREA meeting session at IETF108
2020/07/27 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
So
the
virtual
meeting
tips,
of
course
this
is
a
new
for
us,
but
still
a
few
common
things
if
your
difficulty
joining
just
try
the
calling
option,
but
I
guess,
if
you
are
hearing
me,
then
you're
fine
by
now,
I'm
going
to
ask
you
to
mute
your
mics.
If
you're,
not
on
the
on
the
cube
I
by
now
you
should
be
familiar
with
wordx
and
you
can
join
the
queue
you
can
remove
yourself
from
the
queue
you
can
participate.
A
So
as
a
reminder
for
atf,
this
is
an
etf
official
meeting,
so
you
are
aware
of
the
ietf
processes
and
policies
and
that
any
ietf
contribution
or
participation
in
this
meeting
is
covered
by
those
policies.
If
you
ever
have
any
any
questions
or
you
want
to
see
more
details,
there
are
some
links
here
on
this
page.
A
A
A
A
A
A
A
B
D
A
E
A
E
So
these
last
few
revisions
have
focused
on
the
udp
relay.
We
have
added
all
kinds
of
features
in
order
to
bring
it
up
to
parity
with
turn
and
in
fact
the
current
functionality
supersedes
that
of
turn.
We
have
more
features
and
I
hope
we
haven't
omitted
anything
if
we
haven't,
then
socks
should
be
more
feature-reached
in
turn,
and
it
should
also
be
somewhat
easier
to
use
and
we've
also
added
support
for
icmp
errors,
we'll
see
more
more
on
that
later,
so,
first
up,
we've
refactored
the
messages
used
by
the
udp
relay.
E
So
the
old
message
is
the
association
initialization.
The
association
confirmation
and
the
datagram
messages
still
have
the
same
semantics:
we've
just
refactored
them,
and
they
all
share
the
same
header
that
you
can
see
on
the
left
side.
Now,
not
really,
we've
added
a
message
length
to
all
of
these
relay
messages,
and
this
this
is
somewhat
useless
when
sending
these
messages
over
udp.
But
it's
crucial
once
if
you
want
to
send
them
over
tcp,
so
now,
clients
that
don't
have
access
to
udp
or
dtls
can
send
the
messages
over
tcp.
E
E
So,
let's
talk
a
little
bit
about
supporting
icmp.
So
fundamentally,
icmp
is
a
protocol
that
offers
diagnostics
for
layer.
Three,
the
sox
protocol
abstracts
everything
from
layer
three
below,
so
there
is
no
straightforward
way
of
of
supporting
icmp
with
a
simple
mechanism
that
fits
all
icmp
messages.
So
in
particular,
there
are
two
kinds
of
icmp
messages:
we've
got
echo
and
echo
reply
which
are
not
supported
in
the
current
version.
They
are,
they
have
our
arbitrary
payloads
and
are
very
similar
to
udp.
E
The
the
icmp
messages
that
we
handle
now
are
icmp
errors.
This
is,
they
are
partially
supported
and
this
is
an
optional
feature.
The
reason
why
it's
optional
is
because
of
implementation
and
deployment
concerns.
So,
in
order
to
catch
icmp
messages,
you
need
to
use
raw
sockets
on
linux
or
other
unix-like
systems,
and
the
proxy
also
needs
to
run
as
root.
Obviously
that
can
cause
that
can
cause
problems
for
some
people.
E
So
it's
not
a
core
feature
now
in
particulars
that
we
particularly
support
our
network
unreachable
and
host
unreachable,
ttl
expired
or
pack
it
too
big,
which
is
a
new
feature
in
icmp
v6,
the
other,
the
other
icmp
errors
don't
really
make.
It
doesn't
make
any
sense
to
support
the
other
icmp
error
messages
and
some
some
of
them
are
outright
none
of
the
client's
business.
E
E
So
translating
icmp
errors
is
rather
straightforward.
So
on
the
left,
we've
got
the
sucks
error,
message,
format
and
on
the
right
we
have
an
icmp
error
message,
so
we'll
discuss
we'll
discuss
the
fields
in
the
stocks
error
message
shortly.
So
the
icmp
error
is
exactly
what
you'd
expect.
You
have
one.
You
have
an
ip
header
layered
over,
that
you
have
an
icmp
header
and
the
icmp
payload
contains
the
packet
that
supposedly
was
a
troublemaker,
so
you've
got
you've
also
got
an
ip
header
and
a
udp
header
inside.
E
E
E
E
We've
also
added
some
other
stack
options
for
udp
related
use
cases,
so
you
can
now
fiddle
with
the
with
ttl
that
that
allows
you
to
to
implement
some
kind
of
trace
route
utility
over
socks.
We.
This
was
a
bit
of
a
an
oversight,
but
we
we
we
didn't,
have
we
didn't?
Have
the
functionality
to
set
the
ip
down
fragment
bit?
You
can
now
set
the
df
bit
and
there's
also
some
option
that
enables
you
to
control
the
port
parity.
E
The
rtp
somewhat
some
rtp
implementations
are
rather
picky
about
what
ports
they
run
on
if
they
would
like
would
like
to
run
on
two
consecutive
ports
and
I've
added
an
option.
Two
socks,
that
kind
of
handles
that
I
won't
go
into
details,
but
you
can
look
at
the
draft
if
you
wanna
see
more
about
that
port
parity
option.
E
E
We've
tried
to
handle
all
of
the
new
use,
cases
that
have
cropped
up
and
that
have
led
to
to
the
creation
of
non-standard
proxies,
so
in
particular,
tor
uses.
Some
non-standard
extensions
and
shadow
socks
also
is
non-standard,
in
that
it
makes
liberal
use
of
mptcp
and
tfo
where
it
might
be
problematic,
sometimes,
and
the
rp
relay
has
been
revamped
so
that
it's
much
more
usable
and
that's
about
it
for
me.
So
would
you
like
to
work
on
sucks
v6
in
the
interior
work
group.
A
A
A
B
A
A
A
A
A
A
A
A
F
F
A
F
F
It
is
a
very,
very
broad
topic
that
mostly
it's
it's
a
radio
service,
that's
run
by
amateurs
and
the
main
difference
between
amateur
radio,
licensing
and
the
licensing
of
say
your
mobile
phone
is
your
mobile
phone
is
a
device
that
has
a
license
to
transmit
on
a
set
of
frequencies,
but
with
radio
amateur
radio.
It's
the
operator
that
is
licensed
and
they're
judged
to
be
competent
to
operate
radios
in
various
various
ways.
F
Because
I'm
talking
about
packet,
radio
and
what
I
have
here
is
a
packet
controller
and
you,
you
might
have
memories
of
dial-up
modems,
and
this
is
sort
of
the
same
thing.
It's
going
to
connect
into
the
radio,
take
audio
out
of
the
radio,
put
audio
into
the
radio
and
essentially
play
modem
tones
over
it.
F
F
F
F
But
what
I'm
talking
about
today
is
none
of
these
physical
layers.
Nothing,
that's
actually
touching
the
radio
I'm
talking
about
running
ax25
over
ip
as
an
overlay
network,
to
link
together
amateur
radio
sites
as
a
number
of
applications
that
you
might
run
over
x25
bulletin
board
systems,
mailboxes
keyboard
to
keyboard,
where
you
just
have
a
chat
between
two
stations,
and
you
are
typing
messages
to
each
other
kind
of
an
instant
messaging.
F
There's
standards
for
running
ipv4
over
x25
there's
been
recent
experiments
with
delay,
tolerant
networking
when
you're
running
at
1200
board
the
time
it
takes
to
get
the
packet
out
of
the
interface
is
a
considerable
part
of
the
the
round
trip
time
and
there's
also
systems
like
the
automatic
packet
reporting
system,
which
are
built
on
top
of
x25
to
create
something.
That's
sort
of
like
a
a
real-time
tactical
data
link
and
analogues
would
be
link,
16,
link,
22,
adsb
or
ais
in
the
marine
environment,
and
you
you
have
now
special
purpose
built.
F
F
F
F
These
are
recommendations
because
they're
not
musts,
because,
depending
on
the
deployment
scenarios,
you
might
want
to
change
these
around
and
usually
these
these
are
not
inter-domain
deployments.
They.
They
are
negotiated
between
two
radio
operators
and
they
are
talking
to
each
other
so
that
they
can
change
these
things
if
they
want
the
security
consideration
section,
the
the
integrity
check
is
included
in
in
the
original
protocol.
F
If
a
packet
comes
in
and
that's
transmitted
onto
rf,
you
need
to
have
a
some
way
of
validating
the
source
and
at
the
moment
those
guarantees
are
very
weak.
Also
you
possibly
unique
to
amateur
radio
encryption
is
forbidden
in
some
cases.
It's
a
crime,
so
using
encryption
is
not
a
way
of
satisfying
the
security
considerations,
so
the
recommendations
in
this
draft
are
to
use
ipsec
with
esp
and
use
null
encryption.
F
A
So,
thank
you
very
much
presentations.
I
don't
know
if
you
were
transmitting
over
ax25,
but
you
were
a
little
choppy,
but
fortunately
you
know
the
it
was
very
graphical
in
very
descriptive.
So
if
we
have
any
single
question
because
we
are
short
on
time,
we
can
take
it
quickly.
Otherwise
I
would
encourage
people
to
send
feedback
on
the
list.
We've
already
seen
some
some
feedback,
and
I
mean
this
draft
has
been
going
around
for
a
couple
of
months
at
least
and
we've
had
some
some
interesting
discussions.
D
G
G
G
D
A
G
G
G
G
G
G
H
G
H
H
So
I
don't
have
the
size
right
now,
so
so
we
we
develop
a
new
compression
mechanism
that
is
used
for
these
lp1
networks,
so
one
of
them
is
laura
one
network.
You
have
also
sick,
fox
and
also
ieee,
and
so
this
compression
mechanism
is
quite
original
and
different
from
the
previous
one,
but
of
course
take
also
some
content
from
six
lopan
or
rock
and
then
jacobson.
So
the
goal
is
yeah.
I'm
going
to.
H
That's
good,
so
the
compression
mechanism
is
called
chic
schc.
So
it's
a
static,
contextual
compression.
You
can
go
to
the
this
little
slide.
You
showed
was
good
this
one
yes,
so
it
has
just.
It
has
recently
been
issued
as
an
rfc
and
it's
called
stateless.
It
means
that
you,
you
may
be
the
next
line.
Can
you
show
it
next?
H
H
What
we
do
is
to
check
among
all
this
card,
to
see
the
one
that
produce
the
best
compression
and
when
we
have
found
it,
we
send
the
card
number
some
compression
residue
on
the
rest
of
the
package,
the
data
and
it
arrive
at
the
other
side,
which
must
have
the
same
list
of
cards
of
words
and
from
the
list
of
rules
it
can
reconstruct
the
packet
so
next
line.
Please
so
here
is
an
example
of
rule
that
is
taken
from
the
rfc.
So
the
rule
in
fact,
is
a
list
of
fields.
H
So
we
compare
the
target
value
with
the
field
value
using
the
matching
operator
and
if
all
the
fields
of
the
rule
match
all
the
fields
of
the
packet,
then
we
can
apply
a
compression
and
the
compression
is
described
by
a
compression
decompression
action
and
the
compression
action
can
be
send
the
things,
send
the
field
internally
and
integrate
in
completely
or
send
just
some
bits,
or
we
have
an
index
with
a
list
of
value
and
we
just
send
the
index
on
on
the
opposite
side.
We
do
the
opposite
using
this
this
one.
H
H
H
It
means
that
we,
if
I
for
example
in
lp1
network
you
you
have
a
downlink
that
is,
that
is
very
limited,
so
we
use
bitmap
to
have
feedback
on
this.
Bitmap
tells
you
which
packets
are
well
received
and
which
one
has
not
well
been
received,
and
we
have
a
very
efficient
mechanism
that
is
called
account.
H
Error
and
icon
error
can
reduce
the
feedback
to
one
message:
if
you
have
no
errors
and,
of
course,
the
number
of
feedback
increase
when
the
number
of
error
increased
too
and
we
have
no
hack,
which
is
very
simple-
we
have
no
feedback,
but
when
the
packet
is
received,
we
are
sure
that
it's
correct
or
not
so
next
slide.
Please.
H
So
here
it's
what
I
said
before
is
that
chic
is
a
very
generic
mechanism
that
describes
a
generic
compression
mechanism,
a
generic
fragmentation
mechanism,
and
then
we
have
to
apply
it
to
some
environment.
So
the
first
rfc
describe
how
we
do
udp
and
ipv6.
We
have
described
how
to
do
co-op
compression.
H
A
If
you
have
any
questions,
as
you
can
see,
this
is
a
generic
document
that
has
been
already
approved
and
published
in
the
lp-1,
and
the
idea
is
to
present
here
the
concept,
because
pascal
will
now
talk
about
how
to
apply
the
same
principles
to
a
non-lp1
technology,
and
that's
why
we
need
to
understand
at
least
the
principles
before
understanding.
What
pascal
will
want
to
share
with
us
soon.
A
C
C
Actually,
I
have
added
one
slide,
just
as
a
helper,
so
I'll
go
quickly
through
it,
but
you
you
won't
find
it
in
the
in
the
powerpoint
that
I
uploaded
so
there
we
go
so
you've
seen
that
with
this
new
compression
scheme
check-
and
it
was
initially
designed
for
low
power
wide
area
networks.
But
as
you
know,
there
is
all
the
world
of
existing
legacy
links
like,
for
instance,
gpa
gprs,.
D
A
A
C
C
C
C
I'm
sorry
goes
on
goes
off
and
I
can't
say
why
okay,
so
so,
basically
we
have
enabled
shake
for
lp1,
but
there
is
a
huge
variety
of
links
for
which
it
is
not
enabled,
and
there
was
a
quick
and
easy
way
to
enable
shake
and
all
those
networks
is
to
enable
shakeover
ppp.
So
it's
it's
a
it's
a
good
idea
for
two
reasons.
C
The
first
one
is:
there
are
already
already
compression
schemes
defined
for
ppp,
so
there
is
all
the
mechanisms
in
ppp
to
say
which
compression
you're
using
the
second
thing
is
ppp
gives
us
all
the
legacy
radios
like
your
gprs
phone,
but
with
ppp
and
serial
links.
Obviously,
but
with
pppoe
you
can
get
anywhere,
I
mean
with
ethernet,
you
get
wi-fi,
you
get
pseudo
wires,
you
get
everything.
C
So
we
started
the
work
at
lp1
did
some
review
there,
but
at
some
point
we
we
talked
with
eric
and
the
the
decision
was
that
lp-1
was
not
chartered
to
work
on
ppp.
So
we
better
talk
at
interior,
and
that's
that's
why
we're
here
now
so
we
we
moved
the
draft
to
interior
and
proposed
it
there
and
eric,
maybe
at
the
end,
if
you
want
to,
I
have
a
discussion
if
you
want
to
say
more
words
about
this.
C
So
basically,
this
is.
This
is
like
zero
zero,
but
it's
not
really
because
there
were
two
instances
in
in
lp1
already,
so
the
changes
basically
are
that
I
provided
more
parameters
and
and
basically
chic
is
completely
stateful,
so
you
have
to
say
where
the
compression
state,
which
tells
you
which
bits
go
compressed
and
which
don't
this
must
be
stored
somewhere
and
available
to
both
parties,
the
compressor
and
the
decompressor.
C
This
is
the
the
slide
which
puts
things
in
in
perspective.
So,
as
you
see,
you
may
have
a
device
which
is
not
aware
of
shake,
in
which
case
it's
on
the
left.
It's
what
I
call
the
speaker,
in
which
case
the
router
will
be
doing
the
chic
compression,
but
the
two
devices
on
the
left
could
be
collapsed
in
one
single
device,
which
is
the
ppp
client
and
in
the
example
I'm
giving
it's
ppp
over
ethernet.
C
C
So
if,
if
you
have
split
the
speaker
and
the
router,
then
the
router
needs
to
to
get
to
to
determine
what
the
speaker
is
and
get
the
compression
state
and
that's
what
the
first
arrow
tells
you.
Then
the
next
steps
that
you
can
see
are
classical
ppp
of
the
ethernet.
It's
just
that
when
we
will
be
doing
the
ipv6
cp
negotiation
we'll
have
to
place
this
configuration
well
request.
C
The
configuration
request
we'll
have
to
place
this
option
two,
which
is
the
ipv6
compression
protocol
description,
and
in
this
we
are
actually
adding
the
capability
to
to
say.
Oh,
the
compression
is
going
to
be
check
and
since
there
is
already
in
the
rfc
the
the
way
to
to
express
some
data
which
is
specific
to
this
compression,
the
data
that
we
propose
to
use
here
is
the
url
of
the
compression
state.
C
C
So
the
discovery
which
is
part
of
the
step
defined
by
pppoe
in
pppoe,
it's
it's
a
sequence
of
four
pad
message
by
the
ipad
or
padarpadas
and
they
could
be
replaced
by
anything.
We
don't
necessarily
need
the
bad
message
from
pppoe
to
to
to
find
which
are
the
two
and
the
compressor
under
the
compressor,
but
it's
just
a
logical
option
when
you're
using
pppoi,
so
here
I'm
putting
the
resulting
packet-
and
this
is
an
ipv6
over
ppp
packet.
C
C
B
Yeah,
so
the
responsibility,
this
specific
work
was
impossible
to
take
into
account
in
ip1,
because
the
chart
of
lp1
is
only
for
6v1
and
basically
lp1
layer,
2
networks.
So
the
catch-all
working
group
is
really
interior
here
and
there's
a
reason
why,
with
the
chairs
of
lp1
pascal
and
the
chairs
of
inter
area
was
same
and
jc,
we
proposed
that
this
document
is
adopted.
B
A
We're
going
to
be
very
soon
so
please
send
your
comments
and
questions
to
the
list.
There
were
a
few
on
the
chat,
but
we
don't
have
time
to
go
through
them.
So
I
encourage
you
to
please
think
pascal
on
the
list
about
this
document
and
for
sure
we're
gonna
keep
talking
about
it
over
the
list
and
over
the
next
sessions
so
before
we
are
caught
up.
Thank
you.