►
From YouTube: IETF92-INTAREA-20150326-1740
Description
INTAREA meeting session at IETF92
2015/03/26 1740
A
I'm
in
status,
so
we
have
pretty
much
to
working
group
documents
and
another
one
which
is
not
on
the
slide.
So
the
first
document,
the
GRE
empty
document
we
just
requested
publication,
so
Ted
was
our
ad
and
it
went
on
his
plate,
but
the
working
group
is
changing
hands
to
Brian,
so
we
also
briefed
Brian
now
that,
like
it's
on
his
plate
now,
okay,
so
that
it's
going
to
start
moving
soon
with
ad
evaluation
and
the
other
document
is
like
the
ipv6
GRE
document
which
got
adopted
since
the
last
meeting.
A
So
it's
gone
through
like
two
rubs
already
and
it's
been
actively
discussed
and
so
Ron
is
going
to
present
like
the
updates
and
see
whether
working
group
thinks
so,
as
you
see,
doesn't
that's
pretty
tight
and
so
keep
your
questions
to
a
minimum,
pretty
much
so
like
keep
it
shot
and
then
other
stuff.
We
can
discuss
on
the
mailing
list.
So
let
Fred
get
started.
Okay,
so
excuse
me
so
any
agenda
bashing.
So
anybody
has
issues
with
the
agenda
or.
B
C
Eighty
minus
in
caps
we
can
send
without
fragment
and
because
it's
guaranteed
to
fit
within
the
1280
bite
minimum
to
you,
you
anything
larger
than
1500
bytes.
We
can
send
without
fragmenting,
because
posts
that
send
packets,
larger
than
1500
are
really
supposed
to
be
doing.
Rc
4821,
in
other
words,
sensing,
that
those
packets
are
getting
through
without
being
dropped
by
a
black
hole.
C
So
if
fragmentation
is
needed,
though,
it'd
be
nice,
if
we
could
somehow
tell
the
original
source
that
hey
your
tunnels,
fragment
and
it'd
be
nice.
If
you
get
back
off
and
either
limit
the
size
of
the
package,
you
send
or
do
the
fragmentation
yourself,
and
this
is
what
I'm
calling
an
advisory
packet
too
big
next
chart.
So
what
is
an
advisory
packet
too
big?
C
When
the
tunnel
has
to
fragment
it
can
send
a
packet
too
big
with
a
size,
that's
smaller
than
1280,
subject
to
rate
limiting
it
can
then
either
discard
the
payload
packet
and
treat
the
packet,
the
big
as
a
loss,
indication
or
you
can
fragment
the
delivery
packet
and
treat
the
packet
the
big
message
as
an
advisory
indication.
So
when
a
source
gets
this
packet
too
big
message,
that's
that's
lists
a
size
smaller
than
1280.
C
Unfortunately,
not
all
sources
do
this
and
also
sources
that
don't
do
it
are
non-compliant,
so
the
source
could,
instead
of
doing
that,
reduce
the
size
of
the
packets.
It
sends
to
a
size
smaller
than
twelve
eighty
or
it
could
fragment
future
packets
that
are
no
larger
than
1,500,
so
the
tunneling
you
just
English
doesn't
have
to
fragment.
So
that's
that's
the
results
of
what
an
advisory
packet
too
big
how's
the
source
to
do
next.
C
Chart
the
tunnel
ingress
options
when
a
source
sends
an
atomic
fragment,
an
ipv6
packet,
no
larger
than
1500
with
a
fragment
header,
but
with
more
fragments
set
to
zero
in
ossett
set
to
zero.
The
tunnel
English
can
either
fragment
the
payload
packet
into
two
packets,
then
encapsulate
and
send
both
and
they'll
be
reassembled
by
the
final
destination
which
is
required
to
reassemble
1500
or
it
can
perform
tunnel
fragmentation
on
the
payload
and
encapsulate
and
send
both
fragments
and
separate
delivery.
C
Packets
and
these
fragments
will
be
reassemble
at
the
tunnel
egress,
but
the
ingress
needs
to
know
that
the
reassemble
the
egress
can
be
assembled
as
much.
For
example,
it
needs
to
know
that
there's
at
least
a
2
K
by
minimum.
Mr
you
on
that
side
or
it
can
encapsulate
the
payload
packet,
then
fragment
the
delivery
packet,
and
these
fragments
will
again
be
reassembled
by
the
tunneling
ingress
next
chart,
so
for
non
iqp
encapsulations.
C
We
might
have,
for
example,
I
IP
GRE
Ethernet
encapsulation,
where
Ethan
that
needs
to
see
15
18
bites,
and
there
is
no
such
as
a
package,
the
big
message
in
that
environment.
So
that
means
that
the
egress
must
be
able
to
reassemble
at
least
1518,
plus
and
caps,
and
that
fragmentation
can't
be
avoided
in
all
cases,
so
that
we
might
also
actually
need
sizes
larger
than
15
18
for
some
I
triple
AAA
coatings
Ethernet
within
Ethernet
caps.
Caps
elations
is
another
grey
area
next
chart
so
documents
of
interest.
We
have
this
draft.
C
A
C
B
D
Ok,
second
lightning
present
second
lightning
presentation.
We
were
working
on
a
draft
a
couple
months
ago
that
talked
about
gip
v6
payload
over
GRE
and
GRE
over
ipv6,
and
somebody
pointed
out
that
there's
no
standard
for
either
so
we
decided
to
remedy
that
next
slide.
D
So
we
wrote
a
draft
last
IETF.
It
was
adopted
as
a
working
group
item.
We
got
lots
of
conversation
on
the
mailing
list
between
these
two
I
etfs
from
Fred,
Joe,
told
Lucy
and
Tom
Herbert,
and
we
had
a
few
changes
which
are
summarized
in
the
next
two
slides
first
is
checksum
text.
When
the
delivery
protocol
is
ipv6,
the
GRE
ingress
should
set
the
checksum
present
field
20.
D
D
The
next
change
next
slide
had
to
do
with
the
MTU,
and
it
is
basically
what
you
do
when
you're.
In
a
situation
where
fragmentation
might
be
required,
when
the
GRE
ingress
receives
an
ipv6
payload
whose
length
is
less
than
or
equal
to
the
GMT
you,
the
GRE
ingress,
must
not
fragment
the
payload
or
deliver
delivery
packets.
That
means,
if
you
don't
need
to
pay
to
fragment,
you
must
not.
D
Now,
when
the
GRE
ingress
receives
an
ipv6
payload
whose
length
is
greater
than
the
GM
to
you,
it
means
fragmentation
has
to
happen
and
the
GMT
you
is
greater
than
or
equal
to
1280
Arquette's,
the
GRE
ingress
mount
router
must
discard
the
payload,
send
an
ICMP
PTP
back
to
the
origin
and,
let's
say
whoops,
those
bullets
bullet
shouldn't
be
there,
and
the
MTU
field
should
be
set
to
the
GM
to
you.
So
what
a
thing
is
in
that
nominal
case,
where
the
the
gmt
you,
the
MTU
across
the
tunnel,
is
greater
than
1280
drop.
D
The
packet
send
an
ICMP
ptb
back
to
the
source
next
slide,
and
when
you
need
to
fragment
and
the
gmt,
you
is
less
than
1,200,
then
you
have
a
choice.
By
default,
you
drop
the
packet
and
send
an
ICMP
packet
back
to
the
source.
However,
you
have
a
configuration
option
that
is
on
the
ingress
that
says,
rather
than
doing
that,
I'm
going
to
fragment
the
delivery
up,
encapsulate
the
payload
in
a
single
GRE
header
and
fragment
the
delivery
header.
The
default
behavior
is
to
drop
the
packet
and
send
an
ICMP
back
to
the
source.
D
E
D
I
see
that's
what
we're
arguing
about,
which
is
which
is
the
most
likely
serrio,
I'm
thinking
that
it's
such
an
odd
situation
to
have
a
gmt
you
less
than
twelve
eighty,
that
maybe
you
won't
want
to
think
about
what's
going
on,
but
maybe,
if
it's
not
so
odd,
the
default
configuration
is
backwards
and
it
should
be
the
other
way.
Well,.
E
Yeah
I
think
it
because
you
basically
are
telling
the
hose
that
me
is
to
provide
of
the
tunnel
I'm
screwed
up
that
I'm
telling
you
that
I'm
screwed
up
right,
because
my
gmt
you
is-
is
too
low
right,
okay
and
you're
supposed
to
tell
yourself
not
tell
the
host,
because
the
hose
can't
really
do
anything
about
it.
I'd.
D
E
E
E
G
E
H
J
I
B
You,
oh,
let's
run
so
for
the
GMT.
You
I
think
it
would
be
a
violation.
Y
pues
expects
if
you
didn't,
provide
a
1280
empty
for
a
v6
link,
so
you
have
to
ensure
that
I
think
I'm.
Sorry,
could
you
repeat
that
please
it
would
violate
the
IPC
expects
if
you
cannot
provide
a
link
layer
that
offers
1280
empty
you
larger,
so
I
think
you
have
to
ensure
that
so
I'm
checking
you
know.
Eric's
co
calculates
it
you're
not
with
regards
to
the
fragmentations.
B
2473
has
quite
a
lot
of
text
on
that.
Are
you?
Could
you
ensure
that
you
are
reasonably
in
line
with
that,
so
we
don't
create
two
different
ways
of
fragment
thing.
You
know,
after
an
inner
payloads
here
and
thirdly,
there
are
many
implementations
of
you
know:
I
36
GRE
you
can.
We
also
do
some
work
to
ensure
that
we're
not
creating
an
aspect
here.
That
is,
you
know,
not
interoperable
with
the
existing
implementations.
Okay,.
D
I'll
answer
all
three,
so
it
sounds
like
we
have
two
action
items
first
is
to
switch
the
default
on
what
we
do
when
the
gmt
you
is
small,
second,
is
to
say:
yes,
we
will.
If
you
receive
a
checksum,
you
must
use
it
to
verify
integrity
now,
the
third.
As
for
existing
implementations,
yes,
there
are
existing
implementations
and
they
do
what
the
draft
currently
says.
The
default
is
to
discard
the
packet
so
yeah.
We
have
a
choice
of
doing
what
existing
implementations
do
or
do
the
right
thing.
D
B
B
E
D
E
D
K
I
A
box
magic
box
step
out
of
the
box
and
it
moves
it
rejected
so
I'm
going
to
try
to
do
another
lightning
talk.
This
is
generic
UDP
encapsulation.
It's
a
protocol
kind
of
what
it
says
next
slide,
please.
So,
basically,
what
we're
trying
to
do
here
is
a
generic
extensible,
flexible
and
capsulation
mechanism,
and
this
actually
came
out
of
network
virtualization.
However,
we
did
realize
that
we
could
expand
that
and
basically
have
a
kind
of
a
general
protocol
next
slide,
so
generic
UDP
encapsulations,
its
roots
lie
in
GRE
protocol
looks
a
lot
like
it.
I
Basically,
because
the
GRE
header
length
is
computed
by
interpreting
the
field
bits,
so
GU
kind
of
you
can
think
of
as
a
successor
to
GRE
or
potential
successor,
and
in
it
we
try
to
keep
the
same
model
of
simplicity
and
extensibility.
We
want
opportunities
to
extend
the
protocol,
so
that's
a
big
part
of
this
and
why
we're
at
it
add
a
few
improvements.
I
You
know
that
you
might
have
wish
we
had
in
GRE
next
slide.
So
this
kind
of
a
list
of
the
features
as
I
mentioned,
will
use
flag
fields
much
like
Jerry.
So
if
bit
set,
it
refers
to
a
field,
we
had
a
header
length.
This
is
the
thing
that
allows
middleboxes
to
basically
basically
skip
over
unknown
fields
to
do
deep,
parsing.
I
The
next
header
is
indicated
by
IP
protocol.
Instead
of
ethertype,
we
found
a
few
interesting
uses
for
that
and
also
saving
those
eight
bits
from
the
ether
types
actually
worth
it
in
the
header.
This
is
fundamental,
UDP
encapsulation.
So
it's
much
like
the
other
you
team,
capsule
ations,
so
we
kind
of
get
ecmp
for
free
there.
We
have
a
concept
of
data
messages
and
control
messages.
I
Security
is
a
big
part
of
this,
so
we
actually
define
a
security
field
kind
of
optional,
but
this
is
used
to
authenticate
headers
in
certain
environments.
Yeah
checksum.
We
have
a
checksum
like
jury,
although
this
is
kind
of
the
improved
checksum.
So
it
includes
the
pseudo
header
and
its
UDP
light
so
that
the
checksum
is
only
over
the
header
and
this
solves
problem
and
switches
where
they
don't
want
to
compute
the
full
package
checksum,
but
still
want
to
have
some
sort
of
checks
them
over.
The
header.
Hardly
hardware
friendliness
was
considered.
I
Obviously,
GRE
is
hardware
friendly
by
the
fact
it's
deployed
and
they're
saying
things
that
parse
it
so
we're
kind
of
hopeful
that
that
will
continue,
and
as
I
mentioned,
we
have
support
for
network
virtualization.
It's
like
so
I
won't
go
into
too
much
detail
over
the
gue
headers,
but
we
have
the
normal
version
and
header
length.
Protocol
next
field
c
bit
indicates
whether
it's
a
control
message
or
data
message
and
then
16
bits
of
flags,
and
this
last
flag
is
actually
kind
of
special.
I
It
allows
us
to
extend
the
flags
field
so
that
we're
not
limited
to
16
bits.
We
can
actually
extend
that
to
another
32
bits,
so
conceptually
we
do
this
over
and
over
again
and
have
as
many
bits
as
you
want.
So
it
is,
you
know,
trying
to
think
a
little
bit
forward.
Hopefully
we
won't
wind
up
with
hundreds
of
flags,
but
it
allows
for
that
next
play
UDP.
I
So,
as
I
mentioned,
we
can
use
a
source
port
for
entropy,
much
like
other
European
consolations
UDP
checksum,
very
similar
to
the
MPLS
over
UDP
over
UDP
same
provisions.
However,
since
we
do
have
the
ability
to
add
a
header
checksum
within
the
encapsulation
that
may
mitigate
certain
circumstances
where
we
wish
we
could
turn
on
the
texan,
but
we
can't
because
of
the
switch
compatibility
next
lane,
so
primary
goo
header,
so
I
have
some
detail
here.
I
As
I
mentioned
there,
the
header
length
to
allow
skipping
over
a
product
protocol
see
type
field
serves
two
purposes:
either
it's
an
IP
protocol
or
control
type
and
that's
distinguished
by
the
sea
sea,
but
next
slide.
So,
just
kind
of
an
overview
of
the
headers
I
already
mentioned
that
next
slide
more
on
the
undersea
bit
next
slide.
Please
so
I
will
mention
about
the
flags.
I
This
is
kind
of
an
important
part
of
the
extensibility,
and
one
of
the
things
are
very
careful
about.
The
flags
is
to
make
sure
that
we
have
forward
compatibility,
and
one
of
the
rules
about
the
flags
is
if
a
flag
bit
is
set
and
the
D
capsule
later
does
not
understand
that
flag
bit
packet
is
dropped.
I
So
this
solves
a
lot
of
problems
where,
if
we
want
to
add
a
flag
safer,
the
checksum
receiver
gets
that
and
doesn't
understand
that,
instead
of
just
ignoring
it
in
organic
cut,
some
which
would
be
a
bad
thing,
it
will
actually
drop
the
packet.
So
there
is
an
assumption
here
of
the
ability
to
either
synchronize
or
configure
these
things
upfront,
and
so
you
can
kind
of
skip
the
next
three
slides.
So
this
is
some
more
detail
on
the
flags
in
the
fields
and
what
we're
trying
to
accomplish
there.
I
So
the
protocol
is
designed
to
be
extensible
and
in
fact
we
have
already
defined
five
extensions.
Virtual
virtual
network
identifier
is
for
network
virtualization.
This
is
really
the
only
thing
we
found
specific
to
network
virtualization
is
that
it
needs
this
32-bit
identifier,
security
field,
as
I
mentioned.
This
is
designed
to
allow
either
security
cookie,
potentially
a
secure
hash
over
the
header.
It
is
kind
of
a
multi
length
field
to
allow
some
expansion
in
the
future
header
checksum
I
already
mentioned
remote
checksum
offload
is
a
little
optimization.
I
This
is
based
on
the
fact
that
there's
already
a
large
deployment
of
network
interface
cards
Nick's,
basically
that
support
UDP,
fix
them
off
load,
but
wouldn't
necessarily
understand
how
to
support
something
like
goo,
so
there's
a
little
trick
where
we
can
actually
leverage
these.
You
debase
UDP
support
of
the
outer
checksum
to
offload
the
inner
checksum
tunnel.
Fragmentation
I
think
Fred
actually
alluded
to
this.
We
actually
came
up
with
a
design
to
do
a
tunnel
fragmentation.
I
This
is
kind
of
kind
of
has
some
improvements
over
IP
fragmentation.
So,
for
instance,
we
can
do
a
32-bit
identification
instead
of
16-bit
identification.
So
that's
kind
of
promising.
There
are
a
number
of
potential
possibilities
here
and
I
think
this
is
like
a
normal.
What
are
the
value
value
here?
We're
trying
to
make
sure
that
anything
added
is
is
generic
as
possible
and
in
fact
some
of
these
fields,
like
a
virtual
network
identifier,
security
field,
can
be
fine
in
such
a
way
that
can
be
reused.
I
So,
for
instance,
security
we
could
have
a
64-bit
field,
but
you
could
use
different
algorithms
for
that
and
we
don't
have
to
specify
specify
that
upfront
in
the
definition
of
the
security
field.
So
it's
kind
of
like
repurposing,
the
GRE
key
ID.
We
can
extend
that
model
to
some
other
fields.
Next
slide
private
David
data
Regent.
So
this
is
another
feature
that
we
added
kind
of
to
enhance
Giri
model
a
little
bit.
This
allows,
after
the
last
leg
and
before
the
payload.
I
If
there
is
space
and
they're
determined
by
the
header
length,
this
can
be
arbitrary,
private
data
that
is
inserted
by
the
sender
and
understood
by
the
receiver.
So
it
can
be
a
community
structure.
We
have
one
case
where
people
are
putting
tlv
is
in
there
whatever
and
says
it's
fine.
So
that's
kind
of
kind
of
neat
next
slide
the
status,
so
we
have
three
primary
drafts,
plus
a
few
that
describes
some
of
the
extensions.
The
goo
draft
is
the
base
draft
and
that
describes
pretty
much
the
protocol,
as
is
the
network.
I
Virtualization
draft
is
specific
or
the
MBO
is
specific
to
the
network.
Virtualization
extensions
and
we
have
a
security
draft
describing
the
field.
We
have
a
port
assignment.
This
is
now
an
upstream
Linux,
so
you
can
test
it
out.
If
you
wish,
we
actually
support
IP
IP
/
goo
GRE
over
go
SI
t
/
go
so
one
of
the
reasons
why
I
want
to
come
today
actually
had
a
question,
basically
wick
working
group.
Should
we
consider
this
to
be
on.
So
I
think
that's
one
of
my
fundamental
question.
I
B
J
J
I
I
was
there
and
yes,
I-
do
believe
this
could
easily
kind
of
be
contort
it
to
do
transport
encapsulation
also
so
before
that
we
only
consider
the
tunnel
encapsulation.
This
is
very
similar
to
spot
and,
in
fact,
I
think
there
are
some
things
we
do
need
that
spud
mentioned
like
that
magic
number
to
allow
middleboxes,
22
I
positively,
identify
that
this
is
actually
encapsulation,
so
can
parse
it.
So
I
think
that
would
be
a
good
addition,
but
if
you
kind
of
peel
back
the
onion,
these
become
very,
very
similar
at
some
point.
I
If
not,
if
not
the
same,
for
instance,
one
other
thing
we
need
here
is
probably
dtls
the
original
security
draft
to
ipsec,
but
I
think
dtls
is
much
more
compelling
with
the
UDP
based
protocols.
We
probably
have
that,
in
which
case
the
packets
would
probably
almost
look
identical.
You
couldn't
tell
the
difference
between
the
tunnel
and
a
transport
encapsulation
if
they're
the
payloads
both
encrypted.
All
you
have
is
some
sort
of
encapsulation
header,
I,
don't
know
if
that
was
your
question,
but
well
yeah.
I
B
F
I
I
F
F
I
A
I
Can
give
you
the
precise
example
and
why
we
actually
invented
this
at
Google
was
response
to
our
attempts
to
turn
up
network
virtualization,
so
network
virtualization.
We
needed
a
protocol
and
one
requirement
that
we
had
that
wasn't
satisfied
by
any
existing
protocols,
the
exelon
or
envy
GRE
was
we
needed
a
security
token,
so
we
needed
to
prevent
some
mechanism
prevent
any
spoofing,
basically
and
guarantee
the
integrity
of
the
virtual
network.
Identifier
problem
was
if
the
virtual
network
identifier
became
corrupted,
packets
could
go
to
the
wrong
tenant.
I
This
is
a
serious
breach
of
kind
of
our
first
requirement.
Network
fertilization,
so
we
have
to
add,
have
to
add
something:
GRE
is
the
most
common
I'm,
probably
most
commonly
deployed
encapsulation.
We
would
like
to
extend
that
but
jury.
Besides
the
key
ID
really
doesn't
have
any
usable
fields
that
we
could
put
the
security
in.
We
could
try
to
hack
it
and
overload
some
of
those
fields,
but
pretty
quickly,
even
even
if
we
manage
to
do
that.
I
Well,
we
still
would
like
a
header
checksum,
so
GRE
check
some
very
it's
just
the
payload
doesn't
even
have
a
pseudo
pseudo
header
checksum.
So
can
we
have
a
header
checksum?
That
was
actually
one
of
the
suggestions
from
the
fragmentation
and
tunneling
problem,
so
you
start
to
go
down
that
path
and
realize
wow.
You
know
if,
if
we're
going
to
create
a
new
protocol,
let's
make
sure
it's
extensible
and
you
know
hopefully
last
30
years
and
we
can
predict
we
can
even
meet
the
requirements
in
the
future.
I
A
J
I
I
agree
with
that.
In
some
sense
it
would
have
been
nice
if
we
could
have
put
this
into
either
IP
options
or
ipv6
extension
headers.
But
then
we
run
into
the
common
problem
against
which
support
for
these
and
so
I
know,
Eric
probably
has
feeling
about
this
too,
but
one
one
thing
about
an
encapsulation
header.
In
theory.
We
can
solve
problems
like
that
right,
so
we
could
never
extend
IP
options
because
just
don't
support
it,
but
we
could
start
to
put
this
stuff
in
encapsulation
headers.
I
I'm
not
I'm
not
advocating
that
I
think
it's
a
slippery
slope,
so
we
definitely
need
a
lot
of
diligence
about
where
we
put
these
things.
In
this
case,
the
security
actually
is
tightly
associated
with
a
virtual
network
identifier,
so
I'd
like
those
to
be
logically
together
that
they
are
wanting
the
same.
I
cannot
accept
the
virtual
network,
identifier
without
the
security
saying
it's
it's
valid.
So
that's
that
there
was
a
tight
coupling
to
those
and
there
may
be
alternatives,
but
this
was
actually
pretty
simple
but
interpreted.
J
I
Network
to
be
able
to
parse
to
them
so
middle
yeah,
so
rule
is
middleboxes,
may
inspect
the
headers.
They
do
not
have
to
understand
all
of
the
bits.
They
should
not
drop
it.
If
they
don't
understand
something
they
can
inspect
it.
However,
they
really
can't
change
it,
and
security
probably
prevents
that
because
security
Zhen
nan.
So
if
they
change
the
bits,
it'll
break
the
security,
but
we
do
allow
for
middleboxes
Parsis.
E
Ok,
thank
you.
Ok,
cool!
Not
much
so
I
think
that
on
the
extensibility
thing,
unless
I'm
mistaken,
but
I
thought
that
the
reason
to
have
the
header
length
is
not
only
for
the
middle
boxes,
it's
also
so
that
you
can
potentially
send
a
packet
with
some
new
stuff
in
it,
and
the
D
capsule
ater
can
basically
d
capsulate
it
and
sort
of
silent,
ignore
whatever
it
didn't
understand,
right,
which
we
can't
do
it
with
GRE.
On.
E
I
E
I
Forward
compatibility
problem
and
I
think
we're
seeing
this
in
VX
land.
Another
instance
is
a
router
alert.
So
if
I
add
something
like
a
security
field
and
that's
a
new
field
and
I
send
that
to
someone
who
doesn't
understand
that
field,
it
makes
no
sense
to
ignore
that
you're,
basically
ignoring
a
security
field.
I
So
if
you
look
at
the
extensions
we've
added
I,
don't
I
haven't
seen
one
yet
that
would
make
sense
to
ignore
their
there
may
be
some,
but
for
the
most
part
you
know
if
we
had
something
in
checksum
or
if
we
had
something
like
remote,
checksum
offload
that
is
supposed
to
modify
the
packet
to
fix
up
the
checksum.
We
really
can't
ignore
that.
We
certainly
couldn't
ignore
fragmentation,
because
this
is
not
no
longer
a
packet
that
can
be
received
by
the
host.
So
there
may
be
alternatives
and
we
can
take
it
offline,
but.
B
I
I
E
Some
level
I
mean
I'm,
reflecting
saying-
and
this
is
this
reflection-
but
it's
sort
of
the
inverse
of
today
today
the
middle
boxes
will
drop
everything
they
don't
understand,
or
many
metal
boxes
have
that
behavior
because
they
think
they
know
everything
whether
we
told
them
to
behave
that
way
or
not,
but
but
and
the
endpoints
are
sort
of
more
liberal
than
what
they
accept,
and
this
is
sort
of
the
opposite.
But.
A
So
I
have
a
use
case
like
for
this,
like
it's
incremental
deployment,
but
let's
not
talk
about
it
right
like
so.
We
need
to
first
figure
out
like
that.
This
is
going
to
go
right.
So
what
is
the
status
of
this
at
envy
or
three?
So
because
I
don't
see
anything
in
the
tracker
that
does
not
auction
call
or
anything
so
so.
I
I
A
So
Brian
have
you
had
a
chance
to
take
a
look
at
this
draft.
Okay,.
A
Okay,
so
I
think
of
Eddie,
Brian
yeah,
so
so
I
think
it's
like
what,
while
discussing
this
in
the
entire
email
English.
So
let's
try
to
get
a
discussion
going
on
the
mailing
list
to
see
if
it
like
belongs
here,
but
if
any
or
three
is
willing
to
take
up
the
work
we
can
just
like
last
call
it
here
like
all
over
suggesting
for
the
GRE
raft.
A
I
H
H
H
I
H
I
G
David
black
wearing
a
transport
area
working
group
hat
and
trying
to
make
walked
up
here
with
the
sort
of
a
explanation
sort
of
where
transport
is
and
I
think
overriding
concern
is
that
probably
ought
to
be
one
focal
area
for
this
work
and
right
now
I
guess
I
guess
I
glued
what
I
thought.
I
heard
brian
say
that
the
routing
folks
appeared
of
appear
to
be
leading
the
charge
there.
I
mean
I've
talked
Tom
about
this
draft.
G
E
Yeah
so
I
agree
with
that.
I
think
the
thing
that
we
can,
if
there
are
other
use
cases
that
are
not
tied
to
any
or
three
right,
it
might
make
sense,
discuss
those
use
cases
here
right
because
you
can't
really
discuss
them
over
there
right
and
you
know,
I,
don't
know
if
I
mean
some
of
them
you
already
covered,
but
if
people
come
up
with
additional
ones
that
might
be
one
other
thing
is
that
that
would
be.
D
I
E
I
A
So,
thank
you
very
much
Tom,
so
so
what
we'll
do
is
we'll
take
the
discussion
on
the
list
and
talk
to
the
envy
or
three
chairs
and
the
routing
and
cat
design
team
head-
that's
Eric
over
there,
so
so,
since
David
black
doesn't
want
it
in
tsv
for
now,
so
let's
so,
let's
get
started
from
there
and
see
where
we
want
to
take
this
okay.
Thank
you,
then,.
L
B
L
Here,
okay,
so
so
it's
my
fault,
I
didn't
apply
the
time
sauce
for
the
me
cool
for
some
reason,
so
here
I
think
maybe
I'm
not
as
a
really.
They
me
good
people,
but
I
have
to
make
a
shorter
presentation.
So
what
if
today
is?
We
have
the
architecture?
Work
working
group
draft
between
the
FCA
Turk,
you
so
ted
has
approved
in
this
week,
and
we
also
have
the
mpv
d
id
agree
would
have
been
presented
a
couple
times.
L
We
are
thinking
we
are
going
to
have
a
working
class
call
after
this
meeting
and
also
we
have
the
DCP
support,
MPD
extension
that
has
been
presented
in
dhcp
working
group.
I
think
they
call
comments,
we
are
updating
and
after
the
update
we
are
going
to
have
last
call
together
and
also
the
NDP
extension
also
been
presenting
in
the
sixth
man
working
group.
You
also
got
a
comment
and
we
are
the
update
together
and
also
does
these
three
draft
will
be.
L
We
are
going
to
issue
a
working
girl
at
school
before
next
90
meeting
and
the
first
one
is
a
you
mean
a
TI
document,
so
we
plan
to
how
rewrite
this
document
to
up
adapt
to
the
mpv
d
architectures.
So
we
would
like
to
have
the
major
contributor
to
walk
homeless
and
the
chair.
We
are
coordinating
the
offline
people
about
this
work
and
the
third
one
is
a
problem.
L
Formalism
liaison
work,
so
the
Miffy
walk-in
cooler
has
an
interest
to
what
countries
live
since
last
I
team
meeting
and
we
got
some
of
the
volunteers
and
we
are
thinking
we
probably
as
one
with
a
candidate
proposal
from
itm
to
work
on
this
problem.
We
are
talking
with
a
TS
about
what
we
are
going
to
do
links
that's
it.
Thank
you.
M
The
topic,
the
topic
is
fierce
ipv6
options
for
the
discovery
of
46
48
lat,
ipv6
prefixes
and
the
four
six
four
isolates
provide:
ipv4
connectivity
across
ipv6
network,
using
translation
technology
and
the
you
know:
translation
process
plus
C.
Let's
master
discover
the
pill.
I
said
the
translation,
ipv6
prefix,
salite
and
bending
to
the
destination
IP
v4
dress
into
the
discovered
ipv6
prefixes
to
get
to
the
destination
ipv6
address
and
for
the
multi
papi
lights
scenario.
The
front
of
you
lights
help
me
help
different
ipv6
prefixes.
M
In
this
way,
a
pill
traffic
can
be
attract
attracted
to
the
crack
30
light,
so
our
work
proposes
a
deer's
ap
ways
with
six
based
the
measure.
The
further
pill
pill,
I
said:
ipv6
prefix
the
discovery
and
the
solution.
I
will
show
a
la
finger
first,
a
lusty
light
and
here's
a
few
a6
server
interaction.
The
see,
light
request
to
the
polite
prefix
least
the
option
in
tears,
ap
way
six
requests
and
then
that
use
a
few
a6
server.
Probations
the
pill.
M
I've
said
translation
ipv6
perfectly
stop
by
the
option
and
then
Inga
Inga,
lista,
adoptee
lights,
ipv6,
prefix
and
well
more
polite
Oh,
ipv4
prefix,
a
testers
are
all
contenido
and
the
steel
IT
recorded
the
pill.
I
decided
translation,
ipv6
prefixes
in
Neutron.
In
the
translation
process.
All
the
delights
must
select
the
correct
a
polite
according
to
the
provision,
the
prefix
list
and
the
destination
ipv4
address.
M
Oh
the
correct
ipv6,
the
prefix.
It
can
be
selected
by
the
longest
match
first
to
you
next,
and
there
are
two
options:
define
first
either
Oh
prefect
T
life
prefix
the
least
option.
It
is
a
container
option
for
well
more
of
July
to
prefix
the
option
and
it
is
compatible
with
single
colitis.
If
there
is
only
one
prefixing,
the
prefix,
lista
and
honor
to
define
the
option
is
a
tealight
prefix.
M
A
So,
just
to
provide
everybody
some
background
for
64
X
slide
is
a
transition
technology
that
has
got
done
by
v6,
ops
and
v6.
Ops
is
not
charged
to
do.
Protocol
look
okay
and
it's
a
dhcp
option,
but
dat
working
group
like
doesn't
do
options
for
other
people.
It
reviews
the
options
at
some
point
when
people
do
protocols,
and
so
that's
why
there's
like
no
natural
fit
for
this
work.
So
that's
why
we
are
considering
this
in
interior.
So
just
some
background.
So
not
any
comments.
A
E
So
I
decided
to
come
up
come
up
with
a
long
title,
so
it
was
brought
to
my
awareness
that
we
run
into
these
various
things
that
I
decided
to
call
intentionally
partially
partition
links
or
mouthful,
and
in
exactly
this
one
slide,
you
can
go
to
the
actual
slide
and
I'm
trying
to
investigate
this
stuff
and
I'm.
Basically
standing
up
here,
saying
if
you
have
some
clues
to
impart
on
me
or
you
want
to
help
with
this
stuff.
E
So
these
links
are
they
look
to
IP
as
a
link
in
that
they
have
a
subnet
prefix
but
they're
intentionally,
not
uniformly
forwarding
packets
at
layer,
2
right
and
we've
seen
it
so
typically,
the
way
they
used
is
that
hose
can
talk
two
routers
and
vice
versa,
but
hoes
cannot
talk
to
host
and
we've
seen
at
least
two
examples
of
this
or
I've.
Seen
two
examples
of
this
there's
a
split
horizon
case.
E
That's
used
for
dsl
were
basically
that
the
host
can
chat
with
each
other
described
in
some
dsl
forum
report
and
there's
private
vlans
that
people
deploy
to
sort
of
conserve
on
connectivity
address
space
whatever
there
is
a
solution,
but
they
there's
very
little
little
written
down
how
to
deal
with
the
stuff.
In
the
general
case,
as
far
as
I
know
sort
of
howdy,
how
do
you
configure
things
and
what
works
and
what
doesn't
we
have
a
solution
for
the
specific
cases
split-horizon
that
deals
like
with
dad
right
but
I?
E
Don't
you
haven't
seen
anything
that
says?
How
do
you
do
it?
Do
you
arpan
ND
for
the
general
case,
particular?
How
do
you
do
dad
for
the
more
general
case?
I,
don't
think
that
that
that
that
proxy
dad
thing
necessarily
works
for
the
more
general
case,
which
is
there
in
private
vlans,
because
a
pack
at
the
v
you
have
these
things
that
are
what
is.
E
It
called
I
think
it's
called
community
vlans,
where
some
house
can
talk
to
each
other
and
they
conducted
the
router
there's
some
other
things
that
are
somewhat
related,
which
is
some
filtering
in
RFC
4562,
which
isn't
really
partitioning
the
layer
to
link.
It's
really
as
saying
I'm
going
to
play
with
the
ARP
table
sends
on
filtering
to
get
some
isolation,
behavior
and
I.
E
N
N
Right
it
split
horizon
yeah,
you
basically
each
connection
to
a
subscriber
as
a
separate
channel,
and
so
the
subscribers
can't
talk
to
each
other,
except
through
the
CMT
s.
So
it
behaves
a
lot
like
DSL.
Ok,
well,
different,
so
ed.
Add
that
to
your
list.
The
other
thing
is
that
we've
touched
on
this
kind
of
thing.
N
A
number
of
times
before
you
mention
one
duplicate,
address
detection
that
was
raised
by
the
broadband
forum,
unisex
ops
and
that's
where
that
came
from
another
one
is
really
ancient
history
frame
relay
where
you
have
circuits
underneath,
but
it
looks
like
a
non
broad
nvm.
A
non
project
has
multiple
access
network
and
in
ospf
we
wound
up
with
failure
case.
We
had
to
replace
it
with
point
mulund
interface,
which
is
essentially
a
bundle
of
circuits.
N
E
N
But
so
it's
related,
but
I
yeah,
it's
a
little
different.
You
can
actually
see
the
circuit
we're
well
on
a
CMT
s
or
a
beer,
as
you
can
tell
that
there
is
a
channel
underneath
yeah
you
if
you're,
actually
on
the
beer
ads
or
the
CMT
else.
So
at
any
rate
yeah
we
do
have
some
history
there.
You
might
want
to
take
a
look
at
transfer.
K
Stewart
sure
sure
I
have
a
question.
This
also
sounds
familiar
sounds
similar
to
another
case.
If
I'm
sitting
in
a
coffee
house
with
the
Wi-Fi
access,
I
can't
communicate
with
the
person
sitting
next
to
me,
even
though
we're
on
the
same
access
point,
would
that
be
another
case
profits
this
model
so.
E
It's
so
there's
two
pieces
there
I
think
there's
the
l2
behavior
right
I
ne,
but
then
there's
a
separate
thing
that
doesn't
mean
that
you
can't
communicate
with
TCP,
because
that's
is,
as
far
as
I
can
tell
sort
of
at
a
ACL
policy
question
on
the
actual
router
right.
What
these
technologies
do
is
that
they
force
the
host
to
talk
through
the
router
and
then
on
the
router.
You
can
have
it.
E
I
believe
a
policy
saying:
oh,
this
hose
can
talk
at
layer
3
or
I
will
run
them
through
this
far
wall
and
see
whether
they
can
talk
and
there
might
be
deployments
where
people
say
now.
Hosts
should
never
talk
right.
So
there's
two
pieces
there
that
it's,
the
l2
behavior
that
that
basically
fundamentally
restricts
communication
and
then
there's
potentially
l3
policies
that
further
restrict
things,
but
the
implications
for
things
like
neighbor
discovery,
doubt
whatever
are
is
due
to
the
the
l2
behavior.
K
B
K
K
That
seems
like
a
Miss
configuration,
because,
at
least
in
my
mind
that
the
notion
of
a
subnet,
the
useful
property
of
a
subnet
is
everything
on
the
subnet
is
reachable
by
up
and
everything
that
doesn't
match
when
you
use
the
subnet
mask
has
to
go
through
your
default
gateway,
and
if
you
really
want
to
treat
this
as
a
series
of
point-to-point
links,
then
don't
make
it
look
like
a
broadcast
domain.
If
it
doesn't
behave
like
that,
so
that
it
seems
like
yeah
with.
E
O
Okay,
so
speaking
for
android
york,
yankees
has
almost
any
professionally
done.
Hotel
event.
Wi-Fi
is
another
example.
This
scenario
private
VLAN,
nearly
if
not
all,
Wi-Fi
vendors
allowed
to
prohibit
the
communication
to
in
clients,
and
then
he
says
something
okay.
I
replace
my
previous
comment
with.
Your
comment
is
true.
It
I
may
want
to
save
ND
cash
in
a
network
with
10,000
host
and
I
may
want
to
force
host
to
communicate
via
roll
through
so
yeah
we're.
O
G
It
work
there's
a
there's,
been
a
confusing
multihoming
discussion
in
envio
three
that
might
result
in
a
in
the
converse
of
the
use
case
in
your
second
bullet,
where,
if
the,
if
an
essence
are
the
l2
domain
is,
is,
is
hooked
into
the
virtualization
domain
by
more
by
more
than
one
what
are
effectively
routers,
although
they
may
not
be.
You
can
get
in
situation
in
which
you
want
the
host
talk
to
each
other,
but
you
do
not
want
something
coming
out
of
the
virtualization
domain
by
one
interface,
going
going
going
back
in
I.
G
A
H
H
There's
a
couple
differences
like
the
word
intentionally,
as
opposed
to
you
know,
inherently
by
physics
and
whether
you
are
and
trying
to
preclude
communication
between
hosts
or
whether
you
kind
of
like
to
allow
it.
If
you
could,
if
you
could
and
so
compare
and
contrast,
because
a
lot
of
the
same
issues
are
there
and
whether
you
want
to
address
them
or
not,
may
differ,
and
so
I.
N
H
J
J
So
so
I
just
wanted
to
voice
that
there
is
this
group
and
I
triple
eight:
oh
two
dot,
one
that
is
trying
to
see
how
we
can
best
serve
IP
from
the
lower
layer.
Point
of
view:
okay,
we
don't
have
an
idea.
Yet
we
know
there
are
several
flavors
out
there,
but
it'll
be
interesting.
If
ever
we
need
something
out
of
fatal
to
or
any
coordination
or
any
flag
or
any
thing.
Well,
there's
there's!
No
sorry.
J
Fact
the
only
document
that
it
really
gets
into
this
specific
point,
because
it's
not
the
only
thing
that
only
run
does
right.
But
for
this
specific
point
we
had
a
discussion
about
the
the
net
x,
the
logical
interface
that
this
an
outdated
draft
that
is
being
hanging
there
in
the
metrics.
The
group
for
for
a
few.