Le 25 juil. 2011 à 20:50, Dan Wing a écrit :
>> -Original Message-
>> From: Rémi Després [mailto:despres.r...@laposte.net]
>> Sent: Monday, July 25, 2011 1:43 PM
>> To: Dan Wing
>> Cc: 'james woodyatt'; 'RJ Atkinson'; ipv6@ietf.o
27;; 'RJ Atkinson'; ipv6@ietf.org
> > Subject: Re: PMTUD and MTU < 1280
> > =
>
> > Dan,
> > =
>
> > 1.
> > The point I wanted to check is just, slightly reformulated):
> > "May a simple IPv6 host have no support of packet-reassembly
Dan,
1.
The point I wanted to check is just, slightly reformulated):
"May a simple IPv6 host have no support of packet-reassembly, and simply accept
packets up to 1280 octets."
In my understanding, the answer should be yes.
- This doesn't depend on whether sources know or not whether their dest
> -Original Message-
> From: Rémi Després [mailto:despres.r...@laposte.net]
> Sent: Monday, July 25, 2011 1:43 PM
> To: Dan Wing
> Cc: 'james woodyatt'; 'RJ Atkinson'; ipv6@ietf.org
> Subject: Re: PMTUD and MTU < 1280
>
> Dan,
>
&g
> -Original Message-
> From: Rémi Després [mailto:remi.desp...@free.fr]
> Sent: Monday, July 25, 2011 8:38 AM
> To: Dan Wing
> Cc: 'james woodyatt'; 'RJ Atkinson'; ipv6@ietf.org
> Subject: Re: PMTUD and MTU < 1280
>
>
> Le 23 juil. 2011
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> james woodyatt
> Sent: Wednesday, July 20, 2011 2:44 PM
> To: RJ Atkinson
> Cc: ipv6@ietf.org
> Subject: Re: PMTUD and MTU < 1280
>
> On Jul 20, 2011, at 14:35 ,
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> RJ Atkinson
> Sent: Wednesday, July 20, 2011 2:36 PM
> To: ipv6@ietf.org
> Subject: Re: PMTUD and MTU < 1280
>
> Earlier, Brian Carpenter wrote:
> > It'
In message , Philip Homburg writes:
> In your letter dated Wed, 20 Jul 2011 17:35:31 -0400 you wrote:
> >I am not sure the specs insist that an IPv6 implementation
> >must treat an ICMPv6 Packet-Too-Big for less than 1280 bytes
> >as "unrecoverable". (I haven't re-read the IPv6 specs recently.)
In your letter dated Wed, 20 Jul 2011 17:35:31 -0400 you wrote:
>I am not sure the specs insist that an IPv6 implementation
>must treat an ICMPv6 Packet-Too-Big for less than 1280 bytes
>as "unrecoverable". (I haven't re-read the IPv6 specs recently.)
Some services, like big DNS server cannot af
On Jul 20, 2011, at 14:35 , RJ Atkinson wrote:
> One hopes IPv6 implementers will be tolerant of IPv6 MTUs below 1280 bytes,
> because they do exist in the deployed world and aren't going away anytime
> soon.
Those hopes are not well placed.
I am aware of at least one packet filter implementat
Earlier, Brian Carpenter wrote:
> It's always been my understanding that an interface sending IPv6 packets
> MUST implement some (unspecified) form of framentation and reassembly
> *below layer 3* if the link MTU is less than 1280. In other words a
> PTB for a packet of length 1280 is an unrecovera
In your letter dated Tue, 19 Jul 2011 22:28:03 -0700 you wrote:
>On 7/19/11 6:02 PM, Brian E Carpenter wrote:
>> For example, if you're tunneling IPv6 over an IPv4 network whose PMTU (to
>> the other end of the tunnel) is, to take a random example, 576, the tunnel
>> end points could use IPv4 fragm
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) fo
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 "
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 fo
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 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?
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 shoul
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 d
* 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 do
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.
> B
* 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 130
On 7/18/11 5:25 AM, Karl Auer wrote:
I'm puzzled by something in RFC1981, which discusses PMTUD and IPv6.
It contains these two paragraphs towards the end of Section 4:
A node MUST NOT reduce its estimate of the Path MTU below the IPv6
minimum link MTU.
Note: A node may receive
* Karl Auer:
> I'm puzzled by something in RFC1981, which discusses PMTUD and IPv6.
>
> It contains these two paragraphs towards the end of Section 4:
>
>A node MUST NOT reduce its estimate of the Path MTU below the IPv6
>minimum link MTU.
>
> Note: A node may receive a Packet Too Bi
In your letter dated Mon, 18 Jul 2011 22:25:30 +1000 you wrote:
>I'm puzzled by something in RFC1981, which discusses PMTUD and IPv6.
>
>It contains these two paragraphs towards the end of Section 4:
>
> A node MUST NOT reduce its estimate of the Path MTU below the IPv6
> minimum link MTU.
>
>
I'm puzzled by something in RFC1981, which discusses PMTUD and IPv6.
It contains these two paragraphs towards the end of Section 4:
A node MUST NOT reduce its estimate of the Path MTU below the IPv6
minimum link MTU.
Note: A node may receive a Packet Too Big message reporting a
26 matches
Mail list logo
