►
From YouTube: IETF100-BABEL-20171116-1810
Description
BABEL meeting session at IETF100
2017/11/16 1810
https://datatracker.ietf.org/meeting/100/proceedings/
A
C
D
D
D
E
F
E
I
guess
we
should
go
ahead
here.
This
is
the
Babel
working
group,
I'm
Donald
Eastlake
from
Huawei
yeah,
one
of
the
co-chairs.
E
This
is
the
note
well
which
I
imagine
most
of
you
have
seen
before.
You
should
look
at
it
in
metered.
If
you
haven't
by
contributing
to
this
working
group
or
various
other
area,
IETF
activities,
you're
subject
to
the
IETF
IPR
disclosure
obligations,
it's
a
general
request
to
review
documents.
We'd
only
do.
H
C
E
E
We
have
a
bunch
of
working
group
drafts,
there's
a
short
applicability
draft.
It's
currently
exist
fired,
hopefully
get
rule
reactivated
shortly.
A
information
model
draft
and
the
main
draft
currently
working
on
is
RFC
6120
six
bits.
So
people
who
aren't
aware
of
the
idea
of
the
working
group
primarily
moving
the
existing
experimental
Babel
rfcs
to
standards
track.
So
6126
is
the
base
protocol
draft.
This
is
revision
of
that
which
also
incorporates
extension
mechanisms
and
there's
also
a
source
specific
routing
draft,
which
is
working
with
graph.
E
C
E
There's
a
few
personal
graphs
out
there,
not
at
the
bottom.
This
slide
are
the
existing
experimental
rfcs.
So
we
did
okay
on
the
first
few
milestones,
while
we're
running
a
bit
behind
on
the
current
ones,
but
hopefully
we
can
agent
progress
on
that
RFC
2616
126.
This
has
been
working
group
last
call
and
I
believe
it
announced
to
end
tomorrow,
which
is
when
we
were
going
to
originally
meet.
E
G
Way
when,
while
David
is
getting
ready,
I
thought
I
would
point
out
that
on
the
network,
collective
we've
been
doing
a
history
of
networking
a
series
of
videocast,
and
we
had
Julia's
on
to
talk
about
the
history
of
Babel.
If
anybody
wants
to
go,
find
it
kind
of
cool
listening
to
them,
talk
about
where
it
came
from
instead
could.
A
F
Right
good
afternoon,
everyone,
my
name,
is
David
skinned,
Ozzy
and
I'm
gonna
give
a
quick
update
on
two
of
the
babel
drafts,
so
our
main
one
6126
Biss,
and
these
are
specific
routing.
So
a
lot
of
the
actually
most
of
the
text
and
the
dress
is
not
mine.
It's
Julius's
and
machos.
However,
the
slides
are
mine,
so
any
mistakes.
For
my
fault,
it's
not
theirs
all
right.
So
Joseph
ordered
this
to
the
list.
But
in
case
you
haven't
seen
it.
F
People
are
mentioning
the
Babel
protocol
in
more
and
more
places,
probably
because
it's
blazing-fast
I'm
not
totally
sure
how
that
fits,
but
I
thought
that
was
funny
all
right,
so
kind
of
a
quick
overview
of
what
we've
been
doing
with
6126
base
from
6126.
F
So
I'm
going
to
give
a
quick
detail
of
those,
so
Babel
specified
in
6126
base
mentioned
the
possibility
of
extension
of
sub
T
Oh
is
an
extension
but
didn't
specify
them
that
was
specified
in
a
second
RFC
later.
So
one
of
the
goals
of
6126
base
is
to
unify
those
two
documents,
but
also
we
realized
that
it
would
be
cool
to
have
a
way
to
say
that
sub
chilies
are
mandatory.
What
that
means
is,
if
you
receive
a
sub
Joey
that
you
do
not
understand,
and
that
is
mandatory.
F
F
So
force
or
specific
routing
now,
instead
of
having
a
TLV
for
specific
routing
and
having
like
everything
we
defined
in
there
now,
it's
just
one
sub
T
of
e,
that's
marked
as
mandatory,
and
the
reason
it
has
to
be
mandatory
is
that
if
one
router
treats
a
source,
specific
update
like
a
regular
update,
occurs,
cause
routing
loops.
However,
with
the
mandatory
bit
when
it
sees
it,
it
just
drops
them
so
everything's,
fine
and
one
of
the
other
reasons
is.
F
C
F
However,
with
mandatories
up
to
all
these,
you
can
stack
as
many
as
you
want,
so
those
are
the
main
goals,
and
so
the
other
one
was
unicast
ELO's.
So
there
are
two
reasons
for
those
one
is
performance
because
on
a
few
link
there,
technologies
performance
of
multicast
is
really
bad.
The
most
common
one
is
Wi-Fi,
but
also
there
are
other
technologies,
they
don't
even
support
multicast.
F
So
in
the
original
Babel
spec
you
could
run
every
TLV
on
unicast,
or
would
you
guess,
however,
you
wanted
with
to
accept
acknowledgments
need
to
be
unicast
and
hellos
needed
to
be
multicast.
So
now
we've
introduced
a
new
concept
of
a
unicast
hello
and
that
allows
you
once
you've
discovered
another
house
to
run
the
entire
protocol
of
a
unicast.
So
that's
not
only
more
efficient,
but
it
allows
you
to
deploy
security
with
unicast
swing
solution
such
as
d,
TLS
or
IPSec.
F
F
That's
pretty
cool,
then,
for
those
of
you
who
have
been
paying
even
closer
attention,
I'm
just
going
to
quickly
go
through
the
changes
between
oh
three
and
oh
four.
Clearly,
the
most
important
change
is
that
I'm
now
co-author,
that's
awesome,
but
apart
from
that
things
that
actually
matter,
we
clarified
a
few
things.
There
was
some
confusion
on
the
list
for
some
of
the
data
structures.
One
of
the
really
important
things
about
Babel
is
that
it
only
specifies
the
minimum
of
what
needs
to
be
specified
to
work
really
well
and
a
lot.
F
All
right
never
mind
where
was
I
yeah,
and
so,
however,
it
still
gives
really
good
guidance
for
implementers,
because
really
simple
protocol
to
implement
thanks
to
this
and
part
of
this
was
to
make
sure
that
those
data
structures
are
truly
conceptual
as
guidance.
They
don't
enforce
any
way.
You
don't
have
to
implement
them.
This
way,
we
also
tweaked
how
we
want
it
to
present
unicast
hellos
to
make
to
give
more
flexibility
the
implementers
and
only
give
tips
on
methods
that
had
actually
been
implemented
and
tested.
F
Another
slight
change
that
was
made
was,
on
the
whole
time
one
of
the
problems.
Well,
if
you
were
tracked
a
prefix,
you
can't
immediately
start
routing
people
to
a
larger
prefix
that
encloses
this,
because
that
could
cause
routing
loops.
So
the
initial
Babel
spec
said
you
had
to
have
a
whole
time
like
on
the
order
of
30
seconds
and,
however,
Swann
got
a
first
name
came
up
with
a
better
algorithm,
which
is
you
that
solves
things,
but
you
there's
a
better
property.
F
F
We
we
can
advice
for
how
to
do
running
router
IDs,
and
we
made
a
few
things,
give
more
clear
guidance
on
sending
requests.
So
in
terms
of
next
steps
with
this
document,
it's
in
pretty
good
shape.
The
changes
that
I've
been
coming
lately
are
pretty
minor
and,
as
dalla
was
saying,
we
went
through
last
call,
which
ends
tomorrow
and
might
take
chairs
can
correct
me
is
that
we
had
pretty
good
support.
F
The
one
item
that
I
think
needs
to
be
cleared
up
before
then
is
security
and
I'm
going
to
let
Julius
talk
more
about
that
in
his
talk,
because
I
think
we
all
agree
that
security
was
really
important.
We've
put
work
in
to
be
able
to
make
it
easier.
So,
as
you
can
castelo's
and
then
the
question
that
remains
is
how
we
specifically
solve
this
and
in
what
document,
any
questions
on
61
26
bits
before
I
go
to
shore
specific
routing,
nope
and
so
specific
has
just
a
minor
update
from
below
201
we
are
mature.
F
I
did
more
introduction
background
explaining
what
the
this
extension
accomplishes
and
specified
wodka
request.
The
dash
0
0
had
several
proposals
that
were
up
for
discussion,
the
working
group.
It
we
reach
consensus
that
basically
Walt
care
requests
are
irregardless
of
all
extensions,
so
walk.
Our
request
is,
when
you
ask
another
water.
F
And
we're
back
so
we
are
what
care
requests
are
when
you
ask
another
router
give
it
few
updates
for
everything
it
has,
and
the
question
was:
if
a
router
that
understands
some
extensions
and
so
Walter
requests
the
one
that
I've
sent
some
extensions.
That
cannot
be
the
same
necessarily
the
same
set.
What
you
do
and
the
simplified
answer
is
you
just
send
everything
you
have.
It
makes
all
implementations
simpler,
maybe
at
the
cost
of
some
efficiency,
but
it's
worth
it
and
that's
about
it.
Any
questions.
G
J
By
talking
the
sound
of
a
is
the
echo
bearable,
okay,
so
hello,
so
I'm
julia
scrubber
track
and
I'd
like
to
say
just
a
few
words
to
start
the
discussion
about
babel
security
next
slide,
please
next
slide
yeah,
so
first
I'd
like
to
disclaimer.
None
of
the
ideas
in
this
talk
are
mine,
I'm,
just
going
to
summarize
things
that
have
been
explained
to
me
by
Markus
Steinberg,
Dennis
of
Shankar
token
and
the
audience
and
David
skinny
and
Anton
and
ASIMO,
and
in
rough
chronological
order,
and
so,
if
there's
anything
I
say
today
that
is
wrong.
J
E
J
Thank
you.
So
the
first
thing
I
would
like
to
stress
is
that
babble
is
a
completely
insecure
protocol,
so
I've
been
rather
I've,
been
stressing
this
on
the
mailing
list.
I,
don't
think
we
should
be
saying
that
in
our
in
the
best
RFC
in
the
core
specification
that
babble
is
susceptible
to
such
an
assertion
attack,
we
should
be
extremely
clear
about
the
fact
that
without
any
additional
security
mechanism,
babble
is
susceptible
to
any
sort
of
attack.
So
a
babble
announced
basically
says:
look
folks.
J
I
can
route
back
the
package
to
that
destination
and
if
you
send
a
false
update,
if
you
spoof
an
update
for
ITF
prefix,
then
you
can
pass
yourself
for
say
the
ITF
website
and
redirect
all
traffic
this
time
to
the
IDF's
website.
Now
people
think
that
you
need
to
be
sent
the
network,
sir,
can
achieve
a
lower
metric.
That's
not
the
case.
J
J
J
J
Now
the
other
thing
to
understand
is
that
babble
is
vulnerable
to
replay.
So,
even
if,
for
some
reason
you
cannot
craft
a
false
applause
update,
what
you
can
do
is
capture
a
properly
formulated
say
a
send
to
find
update,
wait
until
it
is
legal
to
send
it
again
for
technical
reasons,
it
will
take
between
a
few
minutes
or
a
few
hours.
So
you
capture
a
lot
of
updates,
and
once
you
have
a
collection
of
AB
days,
you
just
resend
them.
J
J
Now
I
would
like
here
to
fix
the
scope
somehow
somewhat.
There
are
two
basic
approaches,
so
very
roughly
speaking,
there
are
two
approaches
to
authentication:
one
is
the
end-to-end
approach.
You
identified
another
an
announcement
at
this
source
and
every
receiver
of
the
announcement
will
verify
it,
and
the
other
is
the
hub
to
hub
approach.
If,
when
it's
the
only
the
communication
between
net
neighbors,
that
has
a
sanctified
and
any
properly
identified,
node
can
spoof
any
data.
Now
end-to-end
is
the
holy
grail.
J
So
there
has
been
quite
a
lot
of
work
on
security
in
Babel
and
the
user
base
of
Babel.
Basically
using
two
techniques,
one
is
to
use
lower
layer
security.
That
could
mean
a
physically
secure
Ethernet,
but
the
guy
was
a
machine
gun
in
front
of
every
third
neck
socket.
This
can
be
radio
links
protected
by
some
link.
Layer.
J
Protocol
such
as
wpa2
and
people
have
been
running
babel
over
VPNs,
most
notably
oaken
DPN,
and
the
other
approach
is
RFC,
seven
to
nine
eight,
which
is
a
fairly
complete
I'm,
going
to
say
a
few
words
about
it
later
protocol
for
authentication
at
the
application
layer
of
Babel.
Now
this
has
served
as
well.
J
Losers
haven't
been
clamoring
for
other
mechanisms,
however,
we
are
now
aiming
for
standards
track,
and
so
we
need
to
define
one
or
more
security
mechanisms
and,
let's
send
a
clear
message
to
the
user
base,
saying
look
unless
you
have
a
good
reason
to
do.
Otherwise.
This
particular
algorithm
is
the
one
you
should
be
using
for
security.
Please.
J
So
what
are
the
approaches?
I
know
about
for
Babel,
I.
Think
my
analysis
is
that
there
are
two
serious
contenders
for
being
the
one
security
algorithm.
One
is
to
use
an
H
Mac
approach
together
with
a
replay
protection
mechanism.
So
that's
something
similar
to
what
OSPF
does
with
RFC
two
three
to
eight
five:
seven:
nine,
nine,
seven,
four,
seven
four
and
of
course
there
is
Dennis's
extension
for
Babel,
seven,
two,
nine
eight
and
the
other
approach
that
is
being
considered
is
to
use
DTLS.
J
But
DTLS
is
a
unicast
protocol,
and
so
you
need
to
run
babel
over
unicast
and
there
are
other
approaches-
and
I
don't
think
there
are
strong
contenders
right
now,
but
I
wouldn't
like
two
people
to
feel
that
they
should
be
prevented
from
experimenting.
There
is
lower
layer
security
approaches.
There
is
something
similar
to
what
was
proposed
for
DTLS,
but
using
IPSec
I
think
the
person
who
suggested
that
is
in
the
room.
There
is
something
that
users
have
been
clamoring
for
and
that
might
come
in
the
sir
to
some
of
you
plane
tax
password.
J
You
know
you
just
dumped
a
plaintext
password
in
every
babble
packet
and
if
the
passwords
don't
match
you
drop
it,
it
turns
out
that
that
sounds
quite
a
lot
of
problems,
because
most
of
the
so-called
security
problems
are
actually
misconfigurations
I'm,
not
very
keen
on
implementing
that
I.
Don't
know
how
well
it
will
go
and
I'm
in
doubt,
and
I
have
no
doubts
that
there
are
others.
Next,
please.
J
So
the
protocol
that
has
been
suggested
quite
a
lot
due
to
Dennis
of
Shankar,
who
has
who
has
designed
and
implemented
and
written
it
down
in
RFC,
seven
to
nine,
so
it
uses
H
Mac
based
in
integrity
and
a
certain
tenth
occasion.
It
has
algorithmics
ability
with
two
mandatory
to
implement
algorithms
and
it
has
a
fairly
refined
scheme
for
replay
protection
that
doesn't
require
persistent
storage
and
doesn't
require
hardware
clocks
and
that's
important,
because
we
want
to
be
able
to
run
babel
and
embedded
hardware.
Now,
seven
to
nine
nine
eight
is
reasonably
easy
to
implement.
J
I
haven't
implemented
it
myself,
but
I've
checked
Dennis's
implementation.
However,
it's
a
new
security
mechanism
and
some
people
are
a
little
bit
nervous
about
having
a
new
protocol
stack,
and
so
that's
apt,
something
that's
absolutely
great
if
you
need
to
implement
it
from
scratch
and,
as
was
explained
in
Prague
RFC,
seven
to
nine
eight
has
a
rather
subtle
flaw
that
needs
to
be
fixed.
Next,
please.
J
So
the
other
serious
contender
is
DTLS
with
Babel.
So
the
idea
is
the
first
suite
Babel
to
be
a
unicast,
only
protocol
to
use
multicast
for
discovery
only
and
all
the
rest
of
the
protocol.
You
run
over
unicast
duplicating
announcements
to
every
single
neighbor
and
then
the
unicast
traffic
is
protected
using
VT
less
so
DTLS
is
something
you're
not
going
to
re-implement
from
scratch
just
for
babel.
However,
it's
an
already
existing
security
mechanic.
So
that's
a
solution.
That's
great!
If
you
already
have
a
DTLS
stack,
it's
absolutely
horrible!
J
J
So
the
original
plan,
when
I
designed
Babel
back
in
2010,
was
that
any
GL
he
could
be
sent
on
it
over
either
unicast
or
multicast.
And
then
there
are
two
cases
in
which
I
didn't
achieve
that.
Hello's
can
only
be
sent
over
multicast
in
RFC
six
one,
two,
six
and
ax
can
only
be
sent
over
unicast
acts
are
not
you'd
match
in
the
protocol,
but
hellos
are.
You
are
essential
and
in
six
one,
two
six
bits
David
and
pokey
have
fixed
about
one.
J
Now
all
Bible
two
Yogi's
can
be
sent
over
unicast,
so
it's
now
possible
to
implement
Babel
over
unicast
only
and
only
use
multicast
for
discovery.
So
that
means
that
you
can
use
a
unicast
family
security
mechanism
and
it
helps
people
it
pacifies
people
who
have
an
irrational
dislike
of
multicast.
You
know
who
you
are
next,
please
so.
J
We've
started
working
on
that
last
summer,
together
with
Antonin
decimal,
and
he
basically
did
all
the
boring
bits,
understanding
how
it
needs
to
be
done.
What
needs
to
be
done
which
DTLS
library
to
use-
and
at
that
point,
just
as
he
was
going
to
get
to
the
interesting
bits
he
ran
out
of
summer
and
his
work
has
been
extremely
useful.
He
identified
some
tricky
parts.
First
of
all,
we
need
to
decide
which
tlvs
we
allow
in
multicast.
J
J
So
at
some
point
you
have
to
make
the
impendence
of
the
to
the
TTLs
libraries
want
to
use
connected
socket
and
the
Babel
implementation
uses
the
sample
implementation
of
Babel
users
and
connected
sockets,
and
finally,
the
implementation
is
extremely
inefficient
if
you
starts
running
everything
over
unicast
next,
please
so
here
are
some
preliminary
answers
to
that
question.
To
those
questions
the
witch
deities.
Do
you
allow
in
unprotected
packets?
The
simple
solution
is
to
say
hello
only,
but
in
this
case
you
are
allowing
somebody
to
spoof
hello's,
which
makes
you
vulnerable
to
the
US.
J
Is
that
a
problem?
Is
that
not
a
problem
in?
Do
we
want
to
solve
it?
It
can
be
solved
if
this
turns
out
to
be
something
we
don't
what
DTLS
has
time
server
Babel
is
peer-to-peer
well-thought.
You
can
do
that
after
discovery.
You
decide
that
the
guy
with
the
smaller
or
the
larger
it
doesn't
matter,
Rooter
ID
is
the
client
and
the
other
one.
Is
the
server
there's
an
issue?
If
you
do
out-of-band
discovery,
discovery
is
not
being
done
in
the
protocol.
J
You
might
do
discovery
in
some
other
way
that
doesn't
give
you
the
Rooter
ID,
and
at
that
point
you
need
some
other
mechanism
details.
Libraries
won't
connected
sokka's
we're
using
unconnected
sockets,
and
here
it's
a
little
bit
involved.
I
won't
get
into
the
details.
It
was
explained
to
us
by
marker
Steinberg.
You
need
to
run
the
library
in
memory
and
do
all
in
to
talk
with
yourself
and
finally.
Well,
we
do
unicast
inefficiently
in
the
current
implementation,
because
the
current
implementation
does
not
use
unicast
much.
J
J
So
it's
not
my
road
to
tell
people
how
to
work
on,
but
just
in
order
to
start
the
discussion.
I
think
that
we
should
consider
thinking
about
producing
a
revision
of
seven
to
nine
eight
that
fits
well
with
six
one,
two
six
bits
and
solves
the
security
flow
of
the
current
read
the
current
version,
and
ideally
we'd
have
at
least
two
interoperable
implementations.
J
J
Ideally
again,
we
would
have
two
interoperable
implementations
and
we
would
write
down
all
the
tricky
details
that
have
to
be
solved.
I
think
that
if
we
succeed
in
those
two
points,
we
might
be
able
to
publish
both,
but
we
need
to
pick
one,
which
is
the
recommended
one
and
of
course,
if
people
have
other
ideas
and
other
plans,
I
very
much
want
to
hear
about
them,
and
those
two
plans
should
not
prevent
other
people
from
experimenting.
Thank
you
for
your
attention.
F
Deerskin
Ozzy
Apple
thanks
joy,
yes,
I
was
how
we're
getting
some
pretty
bad
echo
from
oh
yeah
I
just
wanted
to
play
that
I
personally
really
prefer
DTLS
to
7298
because
of
the
flexibility
it
gives.
One
example
is
that
you
can
bootstrap
ETLs
lives,
symmetric
keys
or
a
symmetric
keys
or
a
PKI
or
whatever
you
want.
So
it
really
eases
the
trust
model,
which
is
a
question.
F
F
I
would
so
maybe
not
today
is
not
the
right
time,
but
I
would
be
mostly
against
that
because
if
say
you
have
a
use
case
where
you're
running
everything
over
IPSec,
then
you
probably
don't
need
this,
but
I
think
in
a
scenario
where
we
want
things
to
interoperate
like
for
the
whole
net
profile,
for
example,
we
could
make
it
mandatory
and
that
might
be
the
right
solution.
My
mind.
H
H
C
J
H
H
K
As
Steven
biologists
today
ago,
yeah
I
mean
I.
Think
it's
given
that
this
is
a
kind
of
a
greenfield
using
T.
That's
1.3
is
probe,
probably
going
to
be
cleaner
because
you
don't
have
any
backwards
compatibility
issues,
but
DTS
implementations
probably
will
so
you
may
get
the
backwards
compatibility.
So
when
you
go
and
try
and
pick
up
somebody's
code
to
just
do
it
might
make
that
much
difference
so
and
then
are
the
MT
I
think.
K
So
there
is
a.
There
is
a
BCP
that
we
have.
That
says
you
need
to
have
an
empty
ice
security
answer
for
things
like
this.
It
does
have
a
few
get-out-of-jail
clauses
which
might
apply
for
things
like
HomeNet,
because
they're
small,
so
you'd
probably
get
pushback.
So
I
think
if,
if
you
can
come
up
with
something
that
people
are
happy
enough
with
with
everybody
I'm
having
implemented,
that
would
be
better.
So.
J
F
J
So
the
main
point
I
think
it's
premature
to
have
this
discussion
right
now.
Right
now.
We
need
to
have
a
solid
proposal.
We
need
to
have
a
solid
proposal
and
the
solid
X
and
the
solid
implementation.
Once
we
have
a
solid
implementation
and
a
solid
proposal,
then
we
can
do
all
sorts
of
fun
stuff
like
discussing
nti
issues.
F
Sense,
it's
Ganassi,
I
agree
as
well.
I
wanted
to
respond
to
Ted's
point
so
I'm,
not
a
TLS
expert,
but
one
of
the.
As
far
as
I
know
the
changes
into
in
detail.
S13
wouldn't
really
make
big
changes
here.
It's
obviously
a
better
protocol,
however.
Also
TLS
and
DTLS
are
designed
for
forwards
and
backwards
compatibility.
So
whatever
we
come
up
with
I
think
I,
don't
think
the
version
of
TLS
is
a
big
deal.
H
Ted
lemon
again
so
so
the
thing
that
I
remember
and
I
may
be
Stewart.
Sorry,
maybe
Stephen
can
tell
me
whether
I'm
completely
all
wet
about
this
is
I
seem
to
recall
that
DTLS
1.3
is
a
little
bit
easier
to
wrap
into
protocols
that
weren't
really
designed
with
DTLS
1.3
in
mind.
But
that
may
be
a
completely
wrong
recollection,
because.
K
That's
teen
program
and
I,
don't
think
so,
particularly
but
I
think
yeah.
It
certainly
is
worth
looking
us
and
you
know
a
profile
of
DT.
That's
1.3
for
this
might
be
smoother
because
it
is
better
designed.
However,
again
I'd
say
that
I
imagine
the
likelihood
here
is
that
people
won't
write
new
T,
TLS
implementations.
They
just
pick
one
up,
so
it's
going
to
do
all
the
versions,
and
so
you
get
all
the
crap.
C
Barbar
start
so
I.
Some
of
what
I've
heard
about
the
1.3
is
that
they
did
deprecated
a
whole
lot
of
things
as
no
longer
being
permitted
to
be
used,
and
that
certainly
would
be
desirable.
But
it's
my
understanding
that
the
protocol
itself
didn't
vastly
change.
You
know
all
of
the
handshaking
and
all
of
the
underlying
mechanisms,
so
it
it
might
be
useful
to
consider
that
yeah.
C
J
L
C
L
Allah
to
see
the
motivation
of
this
dropped
government's
lack
home
net
may
not
have
hardware
support
for
peer,
encapsulation
and
pure
s,
or
even
support
for
special
Ethernet
type.
It
means
that
and
the
process
in
PR
working
group
there
is
also
am
pure
as
encapsulation
and
Ethernet
an
encapsulation
poppier,
but
the
internet
helpful
for
peer
has
has
not
been
allocated
from
a
Tripoli,
so
there
we
have
only
from
now.
L
Until
now
we
have
only
the
MPS
encapsulation
functions
for
comparing
capsulation
and
the
91
pv6
encapsulation
for
peer
hope,
I
hope
forwarding
in
pure
ipv6
a
Berman's
could
allow
to
process
peer
in
the
slow
path
and
like
a
control,
plane,
processor
and
please
feel
free
to
the
slow
path,
because
we
just
mean
and
the
network
this
kind
of
network.
Folks,
more
than
folks,
more
pay
more
attention
to
service',
divert
diversification,
then
forwarding
efficiency.
So
please
feel
free
to
this
world.
We
not
mean
that
you're,
not
your
network
is
bad.
L
All
your
40,
if
in
just
as
a
too
slow,
no,
no
just
from
feel
free
for
it,
and
the
important
reason
for
fear
is
the
the
most
important
for
this
solution.
Is
here
is
simply
another
next
protocol
for
ipv6
ring,
and
you
know
that
it
will
take
a
long
time
to
achieve
using
at
the
tab
from
my
people
year,
and
so
we
think
this
watching
will,
if
you
explore
the
peer
employee
in
crime,
environment,
so
is
the
solution.
L
The
solution
is
very
simpler
and
the
para
designation
of
ipv6
package'
and
said
to
the
neighbors
link
local
address
or
well
of
the
Lubeck
interested.
Yes,
once
the
destination
is
asserted
to
the
neighbors
loopback
interface
address,
the
edges
should
be
the
same.
Is
the
neighbors
be
AFR
prefix,
that's
its
defining
in
peer
architecture
and
the
source
of
the
packet?
He
should
be.
The
BFI
ask
unified
interface
address,
and
the
address
should
also
be
the
same
as
the
BFI
as
prepare
for
prefix
and
efi
a
means.
The
ingress
router
of
the
domain
when
domain.
L
So
it's
defined
also
defining
impure
architecture
structure
and
the
TD
air
should
be
set
1,
because
we
think
Pierre
is
a
hop
by
hop
forwarding
punching
and
in
order
to
avoid
the
loop
all
the
other
things.
So
we
said
that
if
he
are
said
to
the
set
the
TDR
to
1,
it
will
guarantee
the
beer
for
working
correctly,
and
the
next
protocol
should
be
defined
to
indicate
the
following
pair
packager.
L
Another
flow
ID
is
the
copy
of
entropy
field
in
VR
encapsulation.
So
it's
very
simple.
The
pure
header
is
follow.
Following
the
ipv6
header,
the
Fermata
is
aligned
with
PR
NPA
ampere
as
encapsulation
doctor
for
a
now
and
purest
version.
So
we
know
that
the
s
and
the
PCBs
have
no
significance
here
and
the
pifd
ID
is
also
the
combination
of
stop.
The
man
said:
I
didn't
for
bits,
jinglun
the
remain
feel
the
remaining
fields
are
unchanged,
the
ways
the
PR
and
purest
encapsulation
dropped.
E
E
L
L
J
Is
a
one
thing
that
is
not
entirely
clear
to
me
so
now
we
have
multiple
encapsulations
for
a
beer,
so
suppose
you
have
a
control
protocol.
That
is
so.
You
have
a
control
protocol
that
is
negative,
that
is
announcing
beer
roots,
so
it's
babel
for
argument's
sake.
How
does
it
know
which
encapsulation
to
use
on
a
given
link?
How
do
I
know
that,
on
this
particular
interface,
I'm
going
to
use
the
ipv6
and
encapsulation
rather
than
the
native
encapsulation
I.
L
Of
course,
the
link
local
address
is
true,
but
I
think
the
Lubeck
it's
Ășnica
that
uses
the
loopback
interface
address
of
neighbor,
and
this
and
the
destructor
is
for
the
data
forwarding
plane
of
the
tier
4
of
the
PR
technology,
and
the
previous
slides
is
full
of
coupling
of
104.
How
to
build
is
a
peer
forwarding,
so
if
we
combine
it,
it
worked,
we
can.
We
had
to
be.
Are.
L
C
J
I
Loose
Tony
P,
so,
yes,
correct
is
our
heat
actually
unspecified,
but
if
you
think
through
that,
if
I
announce
to
encapsulations
possible
encapsulations
for
the
same
combination
of
whatever
we
have
their
nose,
subdomain
si
I
can
run
per
link
a
different
encapsulation
of
my
choosing,
okay
and
I.
Think
that's
worth
the
architectural
go
that's
unspecified.
Currently,
though,
with
that
will
be
able
very
easily,
we
will
be
capable
to
very
easily
basically
migrate
from
this
kind
of
hack
right,
which
allows
you
very
quick
deployment
to
something
like.
I
Okay,
it
basically
means
yes,
you
could
and
it
will
behave
in
a
specified
way,
but
the
ultimate
outcome
will
be
the
same,
whether
you
do
that
or
not
because
it's
a
help,
I
hope
forwarding
paradigm,
don't
forget
so
I
know
from
both
sides
that
the
binding
exists.
In
fact,
I
just
need
from
the
destination
site
to
understand
that
the
binding
exists
and.
E
E
So
anyway,
I
guess
we'll
see
people
on
the
list
and
at
the
next
ITF
meeting,
perhaps
in
London
in
March.
So
thank
you
all
for
coming.
I
think
that
people,
mostly
at
this
meeting,
did
an
excellent
job
of
giving
their
name
when
they
went
to
the
microphone
without
even
being
much
that
much,
which
is
pretty
remarkable
and
thanks
to
Barbara
for
volunteering
to
take
notes
and
so
forth.
That's
it.