Why doesn’t IPReassemblytimeout registry key take effect on Windows 2000 or later systems?


I had to deal with a number of support cases where IPReassemblytimeout reg key was set but didn’t take effect on Windows 2003 or a later system and I thought I should be sharing more information about this here. Here are some details:

IP fragmentation is needed when an upper layer packet whose payload is bigger than the IP MTU needs to be sent to a destination. This could happen when the packet initially leaves the host or could happen when a router needs to forward a packet that it received through one interface (with a bigger MTU) to another interface (Smaller MTU). That also happens when packets need to traverse VPN links where there’s an additional VPN related overhead causing the original packet to be fragmented.

The final receiver of the fragmented IP packets re-assembles those fragments and forms the original packet before passing to upper layer protocols. Receiver waits for a period called “re-assembly timeout” for all the fragments that belong to the original packet to be received. If any one of the fragments is dropped on the way, receiver drops the other fragments belonging to the original packet.

In NT 3.1, there was a registry key called “IPReassemblytimeout” (which is referred to by KB 102973). But that registry key doesn’t apply to Windows 2000, XP, 2003, Vista, 2008, Windows 7 or 2008 R2!

Some more facts:

1) IP Re-assembly timeout is hardcoded on Windows 2000, Windows 2003, Windows XP, Windows Vista, Windows 2008, Windows 7 and Windows 2008 R2 and cannot be changed by any means (registry, netsh etc)

2) For Windows Vista, Windows 2008, Windows 7 and Windows 2008 R2, it’s hardcoded to 60 seconds as per section 4.5 of RFC 2460:

“If insufficient fragments are received to complete reassembly of a packet within 60 seconds of the reception of the first-arriving fragment of that packet, reassembly of that packet must be abandoned and all the fragments that have been received for that packet must be discarded.”

For more information, please see RFC2460 (http://www.ietf.org/rfc/rfc2460.txt)

3) For Windows 2000, Windows XP and Windows 2003, it’s at least 60 seconds but it may be higher depending on the value of TTL in the IP header and it may go up to 120 seconds.

Hope this helps..


Comments (8)

  1. Taimur2 says:


    Why is ipReasmTimeout read-only and not writable? It controls the network performance in a way so it should be a parameter that the network manager should be able to control. But then why is it fixed to read-only?



    taimur.ahmed AT live.com

  2. MuratKa1 says:

    I think you would like to understand why it was hardcoded as 60 seconds in the RFC since Windows only implements the RFC itself.

    Here are some opinions on why it wouldn’t be that important to be able to change the timeout value:

    a) Most likely those IP fragments will be carrying TCP segments and TCP retransmission timers will kick in much before that 60 seconds. Of course that doesn’t apply to UDP since UDP doesn’t have such a retransmission capability. At the other hand most of
    the UDP traffic will be transaction based (like ame queries and I don’t think there could be much fragmentation scenarios

    b) Fragments of the same IP packet could be received with high delays (or some of the fragments may not be received at all) between each other most likely because of the following:

    -> The sending party does it on purpose: DoS attacks

    -> Because of incorrect routing configuration, because of packet loss etc

    For the first option, network IDS devices generally detect such attacks. For the other, you’ll need to address the problem with you network infrastructure.

    For the security part, RRAS also has such an option to drop IP fragments rather than forwarding them:


    "You can use filtering of fragmented IP datagrams to prevent the “ping of death,” which is a denial-of-service attack where malicious users send multiple 64-KB ICMP Echo messages. The 64-KB messages are fragmented and must be reassembled at the destination
    host. For each separate 64-KB message, the TCP/IP protocol must allocate memory, tables, timers, and other resources. If a server, including a Windows Server 2003–based computer, receives a substantial number of fragmented messages, it can become overloaded,
    with the result that the servicing of valid information requests is impaired. Enabling the filtering of fragmented IP datagrams causes incoming fragmented IP datagrams to be discarded immediately."

    So if the reason behind reducing the IP re-assembly timeout is security concerns, then there seems to be many different solutions to that (using HW firewalls, Network IDS devices etc)

    Hope this helps



  3. MuratKa1 says:

    Thank you for your comment Taimur.

    I guess it was needed to change that re-assembly timeout value a very long time ago where the connection speed and quality was so low. For now, I couldn't imagine a scenario where such a high delay would occur so that the receiver would need to wait for more than 60 seconds to get all the fragments so that it would be able to re-assemble all the data. Probably RFC2460 takes that into account so that it specifies a hardcoded timeout value of 60 seconds.

    Do you have a scenario where there's such a need?



  4. MuratKa1 says:

    Good to hear that it was some help to you.



  5. MuratKa1 says:

    Hi Taimur,

    Sorry that I haven't dealt with that subject much before so couldn't help you much with that. As you mentioned all these index related objects seem to be serving for the same purpose but there may be some minor differences between. The following document seems to providing some more details in general:

    technet.microsoft.com/…/cc723464.aspx  Network Management and Monitoring

    Hope this helps



  6. Taimur2 says:

    Thanks for your reply.

    No I don't really have a scenario. Just a question posed to us by our instructor.

    I guess its a valid reason that in present times, a delay of 60 secs is unlikely, unlike the slow connections of the past. But what if a manager wants to change this to 30 secs for example? I mean if the manager wants to discard packets if they are taking above 30 secs! In a way discard packets that a taking too much time. Shouldn't in this scenario this parameter be manageable instead of just being read-only?

    What say?

  7. Taimur2 says:

    Thanks for your reply.

    Has been quite helpful in making me understand. Would surely bother you again with some other related questions.

    Thanks again,


  8. Taimur2 says:


    Just had another question. Its about the ipAddrTable.

    ipAddrTable has an object ipAddrEntry (ipAddrTable 1) which has several objects

    ipAdEntAddr -> Index


    3 more…

    My question is "Whats the purpose of ipAdEntIfIndex if not to index?"

    Why is ipAddEntAddr being used as the index here?

    Thanks again!