Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
IP fragments
29 views
Skip to first unread message
Mark
Mar 20, 2013, 12:25:49 PM3/20/13
to
Hello,
I've encountered the following statement somewhere in the net: "Although
theoretically only 8 bytes of L4 info may be guaranteed in a fragment,
assume complete L4 info is available...". I don't understand how possible
that only 8 bytes of a transport are guaranteed in a fragment, as the IP
fragment can't be less than 46 bytes (minimum payload size for Ethernet
frame), and this includes 20 bytes of IP header and 20bytes of TCP header
(not considering variable-lngth options), UDP will be less.
Thus for the first IP fragment we always can expect IP header at tcp header,
while other fragments will carry only IP header + payload.
I believe I'm missing something, but I still can't understand why only 8
bytes can be guaranteed in a fragment? I would appreaciate if someone helps
to clarify this issue. Thanks !
Mark
I've encountered the following statement somewhere in the net: "Although
theoretically only 8 bytes of L4 info may be guaranteed in a fragment,
assume complete L4 info is available...". I don't understand how possible
that only 8 bytes of a transport are guaranteed in a fragment, as the IP
fragment can't be less than 46 bytes (minimum payload size for Ethernet
frame), and this includes 20 bytes of IP header and 20bytes of TCP header
(not considering variable-lngth options), UDP will be less.
Thus for the first IP fragment we always can expect IP header at tcp header,
while other fragments will carry only IP header + payload.
I believe I'm missing something, but I still can't understand why only 8
bytes can be guaranteed in a fragment? I would appreaciate if someone helps
to clarify this issue. Thanks !
Mark
Robert Wessel
Mar 20, 2013, 2:51:08 PM3/20/13
to
glen herrmannsfeldt
Mar 20, 2013, 3:24:11 PM3/20/13
to
(snip)
> Why do you think the minimum Ethernet payload is relevant?
More specifically, IP can have other transport layers, and
even when it is ethernet, it is up to ethernet to pad the
frame before sending it, and for IP to remove the padding
on receiving.
-- glen
>>I've encountered the following statement somewhere in the net: "Although
>>theoretically only 8 bytes of L4 info may be guaranteed in a fragment,
>>assume complete L4 info is available...". I don't understand how possible
>>that only 8 bytes of a transport are guaranteed in a fragment, as the IP
>>fragment can't be less than 46 bytes (minimum payload size for Ethernet
>>frame), and this includes 20 bytes of IP header and 20bytes of TCP header
>>(not considering variable-lngth options), UDP will be less.
(snip)
>>theoretically only 8 bytes of L4 info may be guaranteed in a fragment,
>>assume complete L4 info is available...". I don't understand how possible
>>that only 8 bytes of a transport are guaranteed in a fragment, as the IP
>>fragment can't be less than 46 bytes (minimum payload size for Ethernet
>>frame), and this includes 20 bytes of IP header and 20bytes of TCP header
>>(not considering variable-lngth options), UDP will be less.
> Why do you think the minimum Ethernet payload is relevant?
even when it is ethernet, it is up to ethernet to pad the
frame before sending it, and for IP to remove the padding
on receiving.
-- glen
Dick Wesseling
Mar 20, 2013, 4:26:04 PM3/20/13
to
In article <kicnua$4l0$1...@speranza.aioe.org>,
L4 = Layer 4, i.e. the layer above IP (L1=physical layer, L2=datalink layer,
L3=IP itself). So we're talking about 8 bytes of _payload_.
The IP fragmentation offset in in 8-byte units. So a well-formed IP fragment
- other than the last one - should start at an 8-byte boundary and end at
an 8-byte boundary and its size is therefore a multiple of 8 bytes.
The last fragment may be smaller than that.
L3=IP itself). So we're talking about 8 bytes of _payload_.
The IP fragmentation offset in in 8-byte units. So a well-formed IP fragment
- other than the last one - should start at an 8-byte boundary and end at
an 8-byte boundary and its size is therefore a multiple of 8 bytes.
The last fragment may be smaller than that.
Rick Jones
Mar 20, 2013, 8:00:32 PM3/20/13
to
like 68 bytes. IP MTU is IP header + IP payload and does not include
layer2 stuff. And while the IP header is 20 bytes, I think there can
be some number of IP options - perhaps 40 bytes worth. Thus, after a
68 byte minimum IPv4 MTU, 20 bytes of IP header and 40 bytes of IP
options, there are 8 bytes left for the L4 headers and data.
From RFC 791 we have:
Every internet module must be able to forward a datagram of 68
octets without further fragmentation. This is because an internet
header may be up to 60 octets, and the minimum fragment is 8 octets.
rick jones
--
web2.0 n, the dot.com reunion tour...
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Jorgen Grahn
Mar 21, 2013, 2:50:17 PM3/21/13
to
On Wed, 2013-03-20, Mark wrote:
> Hello,
>
> I've encountered the following statement somewhere in the net: "Although
> theoretically only 8 bytes of L4 info may be guaranteed in a fragment,
> assume complete L4 info is available...".
Do you have an URL for this claim or suggestion? It's suboptimal to
> Hello,
>
> I've encountered the following statement somewhere in the net: "Although
> theoretically only 8 bytes of L4 info may be guaranteed in a fragment,
> assume complete L4 info is available...".
discuss a quote from an unknown source taken out of context.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Mark
Mar 21, 2013, 4:58:51 PM3/21/13
to
"Rick Jones" <rick....@hp.com> wrote in message
news:kidij0$tii$2...@usenet01.boi.hp.com...
[skip]
> I seem to recall something about the minimum IPv4 MTU being something
> like 68 bytes. IP MTU is IP header + IP payload and does not include
> layer2 stuff. And while the IP header is 20 bytes, I think there can
> be some number of IP options - perhaps 40 bytes worth. Thus, after a
> 68 byte minimum IPv4 MTU, 20 bytes of IP header and 40 bytes of IP
> options, there are 8 bytes left for the L4 headers and data.
>
> From RFC 791 we have:
>
> Every internet module must be able to forward a datagram of 68
> octets without further fragmentation. This is because an internet
> header may be up to 60 octets, and the minimum fragment is 8 octets.
Thanks, this clarifies a lot.
> like 68 bytes. IP MTU is IP header + IP payload and does not include
> layer2 stuff. And while the IP header is 20 bytes, I think there can
> be some number of IP options - perhaps 40 bytes worth. Thus, after a
> 68 byte minimum IPv4 MTU, 20 bytes of IP header and 40 bytes of IP
> options, there are 8 bytes left for the L4 headers and data.
>
> From RFC 791 we have:
>
> Every internet module must be able to forward a datagram of 68
> octets without further fragmentation. This is because an internet
> header may be up to 60 octets, and the minimum fragment is 8 octets.
Mark
Mark
Mar 21, 2013, 4:59:47 PM3/21/13
to
"Dick Wesseling" <fr...@securityaudit.val.newsbank.net> wrote in message
news:514a1b5c$0$6913$e4fe...@news.xs4all.nl...
> L4 = Layer 4, i.e. the layer above IP (L1=physical layer, L2=datalink
> layer,
> L3=IP itself). So we're talking about 8 bytes of _payload_.
That's what I was missing out. Thank you.
> layer,
> L3=IP itself). So we're talking about 8 bytes of _payload_.
Mark
0 new messages