* Erik Nordmark:
The motivation for the fragment header insertion was to be able to
support stateless IPv6-IPv4 translators (with multi-path routing),
such as RFC 2765.
Such a translator normally sets DF (don't fragment) in the IPv4
packets. But should the IPv4 path MTU drop below 1300
On Mon, 2011-07-18 at 15:39 -0700, Erik Nordmark wrote:
The motivation for the fragment header insertion was to be able to
support stateless IPv6-IPv4 translators (with multi-path routing), such
as RFC 2765.
Such a translator normally sets DF (don't fragment) in the IPv4 packets.
But
* Karl Auer:
What, exactly, is a node supposed to do when it receives a PTB 1280
after it has sent an ordinary packet?
a) fragment at 1280, regardless of the returned PMTU value
b) fragment so as to produce fragments of sizes equal to or smaller than
the returned PMTU value, but don't
On 7/19/11 4:26 AM, Karl Auer wrote:
Thanks Erik. I've read the explanation in RFC 2765, and sort of see the
motivation, but it doesn't help me understand exactly what the node
should be doing. That is, the why is slightly clearer, but the what
is not.
What, exactly, is a node supposed to do
On 7/19/11 2:00 AM, Florian Weimer wrote:
* Erik Nordmark:
The motivation for the fragment header insertion was to be able to
support stateless IPv6-IPv4 translators (with multi-path routing),
such as RFC 2765.
Such a translator normally sets DF (don't fragment) in the IPv4
packets. But
In your letter dated Tue, 19 Jul 2011 08:18:40 -0700 you wrote:
Then different fragmented datagrams between the same source and dest
traveling through different translators could get the same ID, resulting
in a risk of (persistent) incorrect reassembly.
How can it be persistently incorrect?
If
On 7/19/11 8:51 AM, Philip Homburg wrote:
In your letter dated Tue, 19 Jul 2011 08:18:40 -0700 you wrote:
Then different fragmented datagrams between the same source and dest
traveling through different translators could get the same ID, resulting
in a risk of (persistent) incorrect reassembly.
In your letter dated Tue, 19 Jul 2011 09:36:05 -0700 you wrote:
On 7/19/11 8:51 AM, Philip Homburg wrote:
How can it be persistently incorrect?
Depends whether it is truly random, or pseudo-random, or random initial
value plus an monotonic increment.
Truly random sounds a bit expensive for a
Hello all:
In 6lowpan workgroup, we developed draft-ietf-6lowpan-nd which provides
optimization of IPv6 ND for IEEE802.15.4 devices by avoiding all-node and
solicited-node multicast messages for the most part and providing a method for
device registration with a IPv6 Border router in a
On 2011-07-20 03:15, Erik Nordmark wrote:
On 7/19/11 4:26 AM, Karl Auer wrote:
Thanks Erik. I've read the explanation in RFC 2765, and sort of see the
motivation, but it doesn't help me understand exactly what the node
should be doing. That is, the why is slightly clearer, but the what
is
On 7/19/11 6:02 PM, Brian E Carpenter wrote:
Correct; fragment as if the path mtu was 1280.
But in addition, insert a fragment header even for packets that don't
require fragmentation.
It's always been my understanding that an interface sending IPv6 packets
MUST implement some (unspecified)
11 matches
Mail list logo
