From: Christopher Morrow morrowc.li...@gmail.com
The original version of this discussion started on ipv6@, and was about
what to do if/when a 4to6 (say a nat64 device) translator gets a packet
that would match the criteria in question.
Now that it's morning, and my brain is
From: Francis Dupont francis.dup...@fdupont.fr
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers too)
OK, so what are the other options for encapsulating a packet in a IPv6
packet?
I'm told by
From: Christopher Morrow christopher.mor...@gmail.com
While a non-lisp node receiving a LISP udp/0 packet dropping it seems
fine to me, a translator dropping a udp/0|null-sum packet instead of
translating it properly or telling the source-system: oops, something
bad
From: Brian E Carpenter brian.e.carpen...@gmail.com
I see no particular issue with a network where some LAG-aware routers
do include the flow label in the hash and others don't.
Any time you have a network which is using hop-by-hop path selection (i.e.
each node makes an
From: Margaret Wasserman m...@sandstorm.net
In addition ... this checksum would protect the LISP header, which
contains some one- bit fields and a nonce that would be sensitive to
corruption.
This is an issue I had identified a while back, and looked then to see if
undetected
From: Havard Eidnes h...@uninett.no
in this specific example which is talking about a Link Aggregation
Group (LAG).
I did indeed miss that detail. The conversation had been about a collection
of similar things, including ECMP, and I was thinking of that broader class
of things in
From: Lars Eggert lars.egg...@nokia.com
Alternatively, you could pick a different encapsulation
Dino, why don't we just drop the 'inside IPv6' encapsulations from the spec?
I.e. keep only IPv4 in IPv4 and IPv6 in IPv4? The IPv6 encapsulations could be
documented in a short non-IETF
From: Dino Farinacci d...@cisco.com
Because we want to make all combinations work.
I wasn't saying to drop support for 'IPvN in IPv6' encapsulations from the
protocol, or the implementations. I was just saying take it out of the _RFC_.
Why move it to another draft when the same
From: Lars Eggert lars.egg...@nokia.com
if a transport protocol is used for tunneling IP inside its payload, it
no longer strictly needs to checksum-protect its payload *if* you
require for the inner IP packet and its payload to be protected by some
sort of checksum.
From: Lars Eggert lars.egg...@nokia.com
This is in direct conflict with what RFC2460 says, and I'd personally
would find it problematic to approve publication of an Experimental
protocol that did this, unless there was an IETF consensus on a
standards-track document that
10 matches
Mail list logo
