From: rick.jones2@hp.com   
      
   Martijn Lievaart  wrote:   
   > Ugh. I assume you are talking about HP/UX?   
      
   No.  HP-UX :) And Solaris 2 and at least one version of MacOS (9?) -   
   anything based on Mentat's TCP/IP stack.   
      
   > This behavior caused lots of troubles for us. The least being that   
   > ping was blocked everywhere in our network, so it did not work at   
   > all. Sadly I cannot remember what other troubles it caused, but it   
   > made a lot of architects against PMTUD where there was no real   
   > problem with it, but a huge problem without it.   
      
   > Although I still think the HP/UX implementation was moronic, the   
      
   Difference of opinion on "moronic" - while I think what Mentat tried   
   was ultimately il-advised, it was a clever way to see if PathMTU   
   discovery could "work" to the destination.  If there were no ICMP's   
   coming in response to those ICMP Echo Requests with the DF bit set in   
   the IP header, the "real" traffic would continue to flow with DF   
   cleared, without having to rely on some sort of timeout-based PMTU   
   black hole detection.   
      
   > response by architects and admins to the PMTU troubles in said   
   > network was even more moronic. All token ring interfaces had their   
   > MTU set to 1500. I did predict that the first tunnel would cause no   
   > end of trouble, which it did.   
      
   You had Ethernet and TokenRing networks joined just at Layer2?   
      
   > In the end, as we were responsible for said tunnel, we just forcibly   
   > stripped of the DF bit as it was impossible to convince the network   
   > owners of the correct solutions.   
      
   adde parvum parvo magnus acervus erit :)   
      
   Arbitrarily clearing the DF bit - might as well have set   
   ip_pmtu_strategy to 0 on the HP-UX systems and disabled PathMTU   
   discovery at the root.  Or, if things were otherwise OK apart from   
   what you described below, there was always the value of 1 which set DF   
   always without any of the ICMP Echo Requests being sent (which was   
   value 2)   
      
   > In our part of the network PMTUD did work as designed, except for   
   > one stupid firewall that neither allowed fragmentation-needed errors   
   > by default in an intelligent way, in general, or even could be made   
   > to allow them at all without allowing all ICMP. This was high-end,   
   > expensive stuff...   
      
   rick   
      
   An excerpt from my old "annotated_ndd.txt"   
      
   ip_pmtu_strategy:   
      
       Set the Path MTU Discovery strategy: 0 disables Path MTU   
       Discovery; 1 enables Strategy 1; 2 enables Strategy 2.   
      
       Because of problems encountered with some firewalls, hosts, and   
       low-end routers, IP provides for selection of either of two   
       discovery strategies, or for completely disabling the   
       algorithm. The tunable parameter ip_pmtu_strategy controls the   
       selection.   
      
       Strategy 1: All outbound datagrams have the "Don't Fragment" bit   
       set. This should result in notification from any intervening   
       gateway that needs to forward a datagram down a path that would   
       require additional fragmentation. When the ICMP "Fragmentation   
       Needed" message is received, IP updates its MTU for the remote   
       host. If the responding gateway implements the recommendations for   
       gateways in RFC 1191, then the next hop MTU will be included in   
       the "Fragmentation Needed" message, and IP will use it.  If the   
       gateway does not provide next hop information, then IP will reduce   
       the MTU to the next lower value taken from a table of "popular"   
       media MTUs.   
      
       Strategy 2: When a new routing table entry is created for a   
       destination on a locally connected subnet, the "Don't Fragment"   
       bit is never turned on. When a new routing table entry for a   
       non-local destination is created, the "Don't Fragment" bit is not   
       immediately turned on. Instead,   
      
       o  An ICMP "Echo Request" of full MTU size is generated and   
          sent out with the "Don't Fragment" bit on.   
      
       o  The datagram that initiated creation of the routing table   
          entry is sent out immediately, without the "Don't Fragment"   
          bit. Traffic is not held up waiting for a response to the "Echo   
          Request".   
      
       o  If no response to the "Echo Request" is received, the   
          "Don't Fragment" bit is never turned on for that route; IP   
          won't time-out or retry the ping. If an ICMP "Fragmentation   
          Needed" message is received in response to the "Echo Request",   
          the Path MTU is reduced accordingly, and a new "Echo Request"   
          is sent out using the updated Path MTU. This step repeats as   
          needed.   
      
       o  If a response to the "Echo Request" is received, the   
          "Don't Fragment" bit is turned on for all further packets for   
          the destination, and Path MTU discovery proceeds as for   
          Strategy 1.   
      
       Assuming that all routers properly implement Path MTU Discovery,   
       Strategy 1 is generally better - there is no extra overhead for   
       the ICMP "Echo Request" and response. Strategy 2 is available only   
       because some routers, or firewalls, or end hosts have been   
       observed simply to drop packets that have the DF bit on without   
       issuing the "Fragmentation Needed" message. Strategy 2 is more   
       conservative in that IP will never fail to communicate when using   
       it. [0,2] Default: Strategy 2   
      
   Since ip_pmtu_strategy was created, it has been determined that having   
   ip_pmtu_strategy set to a value of two can allow malicious people to   
   use the system as part of a Denial of Service attack on other   
   systems. For this reason, an HP Security Advisory was issued that   
   suggests the value be either one or zero. In fact, using a value of   
   two is considered "bad" enough that the option is removed from the 11i   
   version of ndd and the default changed to 1, though the ndd -h text   
   may not have been updated in time for the release of 11i (11.11)...   
      
   Setting the value to one will mean that IP datagrams will always have   
   the DF bit set. This is generally fine, but there are still some   
   broken setups out there that will filter-out ICMP "Fragmentation   
   Needed" messages. Trying to send IP datagrams with the DF bit set   
   through such setups will create a "black hole" beyond which systems   
   are unreachable.   
      
   Setting the value to zero will mean that TCP will have to fall-back on   
   other strategies to ensure that its segments are not fragmented along   
   the path to the destination. This could result in TCP using a Maximum   
   Segment Size (MSS) smaller than the maximum possible along that   
   path. This can lead to decreased performance.   
      
   In the HP-UX 11 patch stream, it is possible to set a value of "3" for   
   the ip_pmtu_strategy.  This value will result in the DF bit in the IP   
   header being cleared, but will still have TCP select an MSS based on   
   the link-local MTU.  In effect, it is a way for the network   
   administrator to tell the transport that all (sub)nets are local or   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)