On 7 Feb 2016, at 2:47 PM, Alexey Eromenko <al4321(_at_)gmail(_dot_)com>
wrote:
Hi All,
I'm re-evaluating TCP/IP stack again with my ongoing IP-FF research.
My question: Is packet fragmentation at IP layer even needed ?
Short answer: yes.
Basically here are few possibilities:
1. Fragmentation-and-reassembly at every hop. (I don't know if anybody
implements it)
This is the Internet. Nobody controls every hop. There can be devices who do
this, but it does not force other devices on the path to do this. This would be
slower than passing the fragments as they are, so routers typically don’t do
this unless they’re modifying the packet. Our VPN gateway may or may not
re-assemble and re-fragment when doing IPsec for IPv4, depending on
configuration.
2. IPv4 style-fragmentation -- fragmentation per every hop, reassembly at
destination end.
Definitely implemented widely.
3. IPv6-style-fragmentation -- fragmentation only at source end, reassembly
at destination end.
Definitely implemented by everyone who wants to be compliant with IPv6.
4. No fragmentation at all (the advantage here: faster Router processing vs
#1 or #2 and less implementation bugs); Assuming standard packet size is
defined at 1280 bytes, like in IPv6
5. MTU path discovery via ICMP -- RFC-1981
6. MTU path discovery via TCP (or other Transport) -- RFC-4821 (or other way)
And what if you’re using anything other than TCP/SCTP? If your application is
UDP and it is sending a 3000-byte payload you have to do the fragmentation at
some layer.
I'm leaning towards 4 + 6 solution in my own protocol, IP-FF.
What do you think ?
Should IP layer provide fragmentation ?
Some layer must, and assuming backwards compatibility with existing transport
and higher layers is required, I don’t see how an IP layer without
fragmentation would work.
Yoav