Internet > General Internet

IP Fragments

(1/3) > >>

Weaver:
I was wondering about fragments in IPv4 and IPv6 source fragments. As you may know, intermediate nodes in IPv6 don't fragment packets so that is a big responsibility taken off them -probably was done to make hardware implementation far far less costly.

Do people get problems with fragments getting handled poorly? With IPv4 intermediate fragmented or source fragment or IPv6 source fragments?

I read an article that said that fragmented IPv4 UDP (say) was not handled well at all in practice in the authors experience but I don't know where that was or how general it is.

I also heard some rumours that some firewalls do not react well to fragments. What is your experience?

They can I presume be too paranoid and just bin everything. I doubt they reassemble fragments, it would be very costly but without doing so I imagine they could get fooled. Perhaps a firewall should do a partial reassembly-like thing where it ensures that it at least gets the entirety of the first n bytes of an L3 SDU (ie L3 payload) so it can do its checks, either by assuming that fragmentation in the wrong place, a strange place, when fragment 1 is far too short, is an attack and so it then bins the whole thing. The alternative  would be reassembling/concatenation just enough stuff to get that n bytes together. I am not sure about the need for the latter option though, and it would probably rely on software so could present a DOS attack by eating up CPU time with cases that cannot be dealt with by offload hardware only in a system that has a lot of hardware assist.

Could an application designer just say that fragmentation is not the end of the world? More so in IPv6?

In IPv6, what on earth happens if your path MTU changes on the fly and you are source-fragmenting packets? There is a ‘what is supposed to happen’ and there is a ‘what does happen?’. A real case would be when a failover happens and this causes a change of path, through a reduced MTU.

This is one of the things putting me off going for 3G failover from DSL - MTU reduction on the fly. - was discussed in an earlier thread. I could fix it by reducing MTU all the time, seems a bit harsh. I could just test it, and possibly then ignore the issue of fragmentation.

aesmith:
One of the SIP providers that we use requires so many headers that an outbound INVITE ends up exceeding the size of a normal UDP packet.  Out of interest I just dug out an existing capture and these are in fact fragmented at the IP level, logically one single UDP length 1518 but sent as two IP packets of lengths 1500 and 58.

Weaver:
It seems to me that when fragmenting the fragments should be such that they are roughly if equal sizes, as long as the first one is long enough to contain all the salient L4 (and some L7?) header info for the benefit of firewalls. The reason for making them roughly equal length is to minimise the maximum probability of packet loss due to corruption. I can't see any point at all in having small final fragments.

One really nice thing would be to have a quantisation option for routers, so that you could say that non-final fragments must always be h + c n bytes long (IP PDU length) and this could used to hit the ATM cell payload optimal efficiency sizings, with c = 48 and h = the total overhead size added on below IP, which is 32 for me.

petef:
This is going back a few years but I diagnosed a problem with NFS where a small amount of data got zeroed. The IP packets were fragmented, some were going missing and the reassembly did not flag the gaps. My solution was to reduce the NFS buffer size so that (with overhead) it fitted in the MTU.

Weaver:
@petef that is horrible. Where were the fragments getting lost?

Navigation

[0] Message Index

[#] Next page