On Jun 26, 2013, at 3:56 AM, Mark ZZZ Smith <markzzzsm...@yahoo.com.au> wrote:
> ----- Original Message -----
>> From: Fred Baker (fred) <f...@cisco.com>
>> To: Randy Bush <ra...@psg.com>
>> Cc: IPv6 Deployment Prevention <ipv6@ietf.org>
>> Sent: Wednesday, 26 June 2013 1:30 PM
>> Subject: Re: New Version Notification for 
>> draft-bonica-6man-frag-deprecate-00.txt
>> 
>> On Jun 25, 2013, at 12:42 PM, Randy Bush <ra...@psg.com> wrote:
>>> in reality, you can not count on pmtud working
>> 
>> One of these days, I'll understand why Linux/FreeBSD/Windows/Apple don't 
>> implement RFC 4821. 
> 
> Actually, Linux does, it just needs to be switched on in /proc/sys/net/ipv4/
> tcp_mtu_probing - INTEGER Controls TCP Packetization-Layer Path MTU 
> Discovery.  Takes three values: 0 - Disabled 1 - Disabled by default, enabled 
> when an ICMP black hole detected 2 - Always enabled, use initial MSS of 
> tcp_base_mss.

In other words, it's not on. There is some dead code there, but unless you are 
the writer of the application or a Linux techie, it doesn't work for you.

> I think Windows also implements something similar:
> "
> Troubleshooting PMTU Black Hole Routers"
> http://technet.microsoft.com/en-us/library/cc958871.aspx

"To respond effectively to black hole routers, you must enable the Path MTUBH 
Detect feature of TCP/IP."

In other words, it's not on. There is some dead code there, but unless you are 
the writer of the application or a Windows techie, it doesn't work for you.

My question isn't whether there is some experimental code somewhere that could 
possibly implement it if someone rewrote the application or did some surgery in 
the system's configuration files. If my daughter bought a standard system and 
started using it, would it work for her? My question is why folks aren't 
implementing it in the normal case. Experimental code is kind of pointless in 
the general case.

> One of the issues with conventional ICMP PTB based PMTUD is the default rate 
> limits on ICMP messages on broadband routers with PPPoE subscribers i.e. 
> dumbell [1500][1492][1500] MTUs, slowing down PMTUD. Upping the limit on ICMP 
> PTBs is an obscure parameter to have to remember to change, and it isn't 
> clear exactly what to change it to - IIRC, the value I've used in the past is 
> 1000/s up from 10/s. RFC4821 would be nice because it would avoid control 
> plane processing that ICMP based PMTUD causes.
> 
> Regards,
> Mark.

If at first the idea is not absurd, then there is no hope for it.  
Albert Einstein




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to