[lkml]   [2002]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: IPv6 PMTU/MTU related patch for 2.5.31 kernel


I think it needs to be RFC conformance for PMTU to avoid unnecessary
probing PMTU network traffics. For UDP and ICMP which doesn't have any
reference on this kind of route, the route needs to be around for a while
instead of being delete within a very short time even immediately.

Shirley Ma

Andi Kleen <> on 08/28/2002 02:44:34 AM

Sent by:

To: Shirley Ma/Beaverton/IBM@IBMUS
cc:,, LTC IPv6
Subject: Re: IPv6 PMTU/MTU related patch for 2.5.31 kernel

"Shirley Ma" <> writes:

> + /* If there is no reference to this route, this route will be
> + deleted by fib6_run_gc() within 30 secs. The cached
> + PMTU will be gone. It's possible to be deleted before any
> + other protocol using it. Then the old larger pmtu will be
> + which against RFC1981: detect an increase MUST NOT be done
> + less than 5 minutes after a Packet Too Big Messages has
> + been received for the given path.
> + */
> + dst_hold(&nrt->u.dst);

This seems overkill and could potentially tie up quite a of dst
entries for dubious purposes. This RFC requirement clearly cannot be
followed in all cases, e.g. when you run out of memory for the
destination cache. This is one such case too.

I think only following it when there is still another reference to the
dst entry (e.g. from a socket) is reasonably near the spirit of the


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.037 / U:2.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site