Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: IP Fragments  (Read 488 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 5376
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
IP Fragments
« on: May 25, 2018, 09:12:08 AM »

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.
Logged

aesmith

  • Reg Member
  • ***
  • Posts: 701
Re: IP Fragments
« Reply #1 on: May 25, 2018, 01:12:53 PM »

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.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 5376
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: IP Fragments
« Reply #2 on: May 25, 2018, 01:50:12 PM »

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.
Logged

petef

  • Member
  • **
  • Posts: 76
Re: IP Fragments
« Reply #3 on: May 25, 2018, 04:46:00 PM »

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.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 5376
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: IP Fragments
« Reply #4 on: May 25, 2018, 04:51:01 PM »

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

petef

  • Member
  • **
  • Posts: 76
Re: IP Fragments
« Reply #5 on: May 25, 2018, 09:58:46 PM »

It was NFS v2 and so was using UDP. That allows packets to be lost, it is up to the NFS client or server to request retransmission. IIRC it was the IBM server that was failing in its duties.
Logged

CarlT

  • Reg Member
  • ***
  • Posts: 827
Re: IP Fragments
« Reply #6 on: May 26, 2018, 12:49:40 PM »

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.

You're still transmitting the same amount of data. If you send 2000 bytes over, say, TCP, whether you send as 2 x 1000 byte payloads of 1 x 1460 byte payload and 1 x 540 byte payload you're still sending 2116 bytes at the Ethernet level, be it 1518 + 598 bytes or 2 x 1058 bytes. Ethernet is not a fixed cell size transport, just a maximally limited one. If you can't fill a frame you don't send the rest of it as nulls unlike ATM, you just send a smaller frame and leave the wire idle.
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5396
Re: IP Fragments
« Reply #7 on: May 26, 2018, 01:21:06 PM »

weaver PF reassembles fragments not sure off hand about iptables
« Last Edit: May 26, 2018, 11:19:42 PM by Chrysalis »
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 5376
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: IP Fragments
« Reply #8 on: May 26, 2018, 01:59:47 PM »

@Ignitionnet - no, I meant this as an optimisation for cases where you know some poor devil will end up having to use an ATM link. That’s all. Did you think I misunderstood? Or am I getting confused? :-)
Logged

CarlT

  • Reg Member
  • ***
  • Posts: 827
Re: IP Fragments
« Reply #9 on: May 27, 2018, 12:55:00 PM »

Ah okay. Thankfully ATM is basically history so we are all good for that. A product of its time, left behind by MPLS.
Logged

CarlT

  • Reg Member
  • ***
  • Posts: 827
Re: IP Fragments
« Reply #10 on: May 27, 2018, 07:46:27 PM »

I should stress that the product I discussed earlier is not a simple packet pusher - it inspects every packet traversing it, limiting throughput on a single hardware box to a few gigabits per second across WAN, though obviously as tech and business case require it can go much higher. It's just about how much RAM, how many CPUs and, if doing WAN optimisation, how fast the storage is.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 5376
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: IP Fragments
« Reply #11 on: May 27, 2018, 08:05:45 PM »

@ignitionnet I would like to see that. Good that I'm not the only one thinking about this.
Logged

CarlT

  • Reg Member
  • ***
  • Posts: 827
Re: IP Fragments
« Reply #12 on: May 27, 2018, 08:25:23 PM »

Here's some stuff. SD-WAN is likely the next big thing. ATM took over from point to point lines, MPLS from ATM, SD-WAN is probably the next evolution taking over from MPLS.

https://www.sdxcentral.com/sd-wan/definitions/software-defined-sdn-wan/
https://en.wikipedia.org/wiki/SD-WAN

You are welcome to message me if you wish for further insight on this technology.
Logged
 

anything