How does a TCP segment fit into a smaller IP packet?
Clash Royale CLAN TAG#URR8PPP
The IP protocol can handle fragmentation and it includes the fragmentation offset and identifier. I know this comes into play when your IP packet is too big for some specific network or link where the MTU is lower then the previous one.
For example, the MTU is 1000 bytes, and your IP packet is 900 (+20) bytes. Further down the line the MTU is only 500, so you have to extract the IP data and put it into two packets, one of them 480 (+20), and the other one 420 (+20).
But from my understanding this is fragmentation in the Networking layer, turning an IP packet into multiple IP packets. Meaning that you only have the Transport Layer Header present one time, and a new Network layer header for each smaller IP packet.
I hope my understanding of this is correct. Anyway, after the image comes my actual question:
Let's say your IP packet length is limited by 1000 bytes including the header, due to the MTU of 1000 bytes.
What actually happens if for some reason your TCP segment is bigger than 980, thus exceeding the maximum IP packet size?
What if your TCP segment is 1960 bytes. How is the fragmentation handled here? Is it put into a 1980 IP packet, which is then fragmented into two 980 (+20) IP packets?
Does the fragmentation occur before this, in the transport layer? Are multiple smaller transport layer segments, each with its own header sent into the IP layer with the correct size?
ip network transport-protocol fragmentation
add a comment |
The IP protocol can handle fragmentation and it includes the fragmentation offset and identifier. I know this comes into play when your IP packet is too big for some specific network or link where the MTU is lower then the previous one.
For example, the MTU is 1000 bytes, and your IP packet is 900 (+20) bytes. Further down the line the MTU is only 500, so you have to extract the IP data and put it into two packets, one of them 480 (+20), and the other one 420 (+20).
But from my understanding this is fragmentation in the Networking layer, turning an IP packet into multiple IP packets. Meaning that you only have the Transport Layer Header present one time, and a new Network layer header for each smaller IP packet.
I hope my understanding of this is correct. Anyway, after the image comes my actual question:
Let's say your IP packet length is limited by 1000 bytes including the header, due to the MTU of 1000 bytes.
What actually happens if for some reason your TCP segment is bigger than 980, thus exceeding the maximum IP packet size?
What if your TCP segment is 1960 bytes. How is the fragmentation handled here? Is it put into a 1980 IP packet, which is then fragmented into two 980 (+20) IP packets?
Does the fragmentation occur before this, in the transport layer? Are multiple smaller transport layer segments, each with its own header sent into the IP layer with the correct size?
ip network transport-protocol fragmentation
2
The TCP MSS is based on the MTU.
– Ron Maupin♦
Jan 19 at 19:37
add a comment |
The IP protocol can handle fragmentation and it includes the fragmentation offset and identifier. I know this comes into play when your IP packet is too big for some specific network or link where the MTU is lower then the previous one.
For example, the MTU is 1000 bytes, and your IP packet is 900 (+20) bytes. Further down the line the MTU is only 500, so you have to extract the IP data and put it into two packets, one of them 480 (+20), and the other one 420 (+20).
But from my understanding this is fragmentation in the Networking layer, turning an IP packet into multiple IP packets. Meaning that you only have the Transport Layer Header present one time, and a new Network layer header for each smaller IP packet.
I hope my understanding of this is correct. Anyway, after the image comes my actual question:
Let's say your IP packet length is limited by 1000 bytes including the header, due to the MTU of 1000 bytes.
What actually happens if for some reason your TCP segment is bigger than 980, thus exceeding the maximum IP packet size?
What if your TCP segment is 1960 bytes. How is the fragmentation handled here? Is it put into a 1980 IP packet, which is then fragmented into two 980 (+20) IP packets?
Does the fragmentation occur before this, in the transport layer? Are multiple smaller transport layer segments, each with its own header sent into the IP layer with the correct size?
ip network transport-protocol fragmentation
The IP protocol can handle fragmentation and it includes the fragmentation offset and identifier. I know this comes into play when your IP packet is too big for some specific network or link where the MTU is lower then the previous one.
For example, the MTU is 1000 bytes, and your IP packet is 900 (+20) bytes. Further down the line the MTU is only 500, so you have to extract the IP data and put it into two packets, one of them 480 (+20), and the other one 420 (+20).
But from my understanding this is fragmentation in the Networking layer, turning an IP packet into multiple IP packets. Meaning that you only have the Transport Layer Header present one time, and a new Network layer header for each smaller IP packet.
I hope my understanding of this is correct. Anyway, after the image comes my actual question:
Let's say your IP packet length is limited by 1000 bytes including the header, due to the MTU of 1000 bytes.
What actually happens if for some reason your TCP segment is bigger than 980, thus exceeding the maximum IP packet size?
What if your TCP segment is 1960 bytes. How is the fragmentation handled here? Is it put into a 1980 IP packet, which is then fragmented into two 980 (+20) IP packets?
Does the fragmentation occur before this, in the transport layer? Are multiple smaller transport layer segments, each with its own header sent into the IP layer with the correct size?
ip network transport-protocol fragmentation
ip network transport-protocol fragmentation
asked Jan 19 at 19:33
MyntektMyntekt
403
403
2
The TCP MSS is based on the MTU.
– Ron Maupin♦
Jan 19 at 19:37
add a comment |
2
The TCP MSS is based on the MTU.
– Ron Maupin♦
Jan 19 at 19:37
2
2
The TCP MSS is based on the MTU.
– Ron Maupin♦
Jan 19 at 19:37
The TCP MSS is based on the MTU.
– Ron Maupin♦
Jan 19 at 19:37
add a comment |
2 Answers
2
active
oldest
votes
After the routing decision is made for a given packet, it is scheduled to go out of a particular interface. If the packet is too big for the MTU of the link, it is sent as two or more IP packets containing fragments. The details are in Internet Protocol RFC 760 section 2.2, but in brief the first one has the beginning of the packet including the TCP header, and the later ones are just continuations. The receiver can tell there are more by the "More Fragments" flag in the header, and sees where they go by the Fragment offset.
As the beginning of the IP packet payload is in the first fragment, only the first fragment has the TCP header. The subsequent fragments will just begin with their appropriate part of the payload, probably bytes from the middle of the TCP stream.
This mechanism is IPv4-specific, and isn't directly related to the content of the packet. TCP tries to keep the packets inside the MTU by adjusting the maximum segment size of the TCP stream, but if the MSS is too high, you'll get the fragmentation.
Remember there's also a "Don't Fragment" flag, which if implemented, means instead of forwarding the fragments, the system will drop the packet and send an ICMP error back (unless configured not to).
Remember also that this "do I need to fragment this packet" question happens for every packet going out of every interface. Even if the interface out of a server has a MTU big enough for a given packet, some router along the way might have a much smaller MTU -- this is the "path MTU" issue. Any routing change, such as for load balancing or fault recovery, can change the path MTU. As a consequence of this, it's legitimate for fragments to arrive in the right order, overlap, be partially duplicated.
Finally, don't forget that fragments can be misformed on purpose: such as sending duplicate portions of the data, which can lead to some unpleasant security problems. Consequently many routers and firewalls do a certain amount of reassembly even though strictly speaking they don't this isn't needed to do the router's job -- it could just forward the fragments.
So what you're saying is that whatever packet size there is for TCP, the IP will encapsulate it with its own header, and then when leaving the interface it is split into multiple packets if needed?
– Myntekt
Jan 19 at 19:41
Yes, nothing specifically to do with TCP. This is an IP function.
– jonathanjo
Jan 19 at 19:42
add a comment |
How is the fragmentation handled here?
We have to distinguish two cases:
Case 1: Layer-2 does not allow a frames of such a length
In this case an IP packet of 2000 bytes size (or whatever size is required) is built and the TCP segment is inserted into that 2000 byte IP packet.
This packet will be fragmented on IP layer (layer-3) so it can be transmitted in fragments of let's say 500 byte size..
This happens completely on IP layer; TCP layer does not know that the IP packet of 2000 bytes size is fragmented.
Case 2: IP packet sizes are restricted
In some cases the sizes of IP packets may be restricted. (As an example there are some CGNATs allowing IP packets of limited size only.
In this case the TCP layer (layer-4) simply cannot send segments of such a long size.
In the first packet of a TCP connection both computers involved in a connection can tell the other computer the maximum size of a TCP segment the computer is able to receive.
If a computer supports only IP packets up to 800 bytes size, it may tell the other computer that TCP segments of up to 700 bytes are supported, so the resulting IP packet will be less than 800 bytes long.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "496"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f56254%2fhow-does-a-tcp-segment-fit-into-a-smaller-ip-packet%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
After the routing decision is made for a given packet, it is scheduled to go out of a particular interface. If the packet is too big for the MTU of the link, it is sent as two or more IP packets containing fragments. The details are in Internet Protocol RFC 760 section 2.2, but in brief the first one has the beginning of the packet including the TCP header, and the later ones are just continuations. The receiver can tell there are more by the "More Fragments" flag in the header, and sees where they go by the Fragment offset.
As the beginning of the IP packet payload is in the first fragment, only the first fragment has the TCP header. The subsequent fragments will just begin with their appropriate part of the payload, probably bytes from the middle of the TCP stream.
This mechanism is IPv4-specific, and isn't directly related to the content of the packet. TCP tries to keep the packets inside the MTU by adjusting the maximum segment size of the TCP stream, but if the MSS is too high, you'll get the fragmentation.
Remember there's also a "Don't Fragment" flag, which if implemented, means instead of forwarding the fragments, the system will drop the packet and send an ICMP error back (unless configured not to).
Remember also that this "do I need to fragment this packet" question happens for every packet going out of every interface. Even if the interface out of a server has a MTU big enough for a given packet, some router along the way might have a much smaller MTU -- this is the "path MTU" issue. Any routing change, such as for load balancing or fault recovery, can change the path MTU. As a consequence of this, it's legitimate for fragments to arrive in the right order, overlap, be partially duplicated.
Finally, don't forget that fragments can be misformed on purpose: such as sending duplicate portions of the data, which can lead to some unpleasant security problems. Consequently many routers and firewalls do a certain amount of reassembly even though strictly speaking they don't this isn't needed to do the router's job -- it could just forward the fragments.
So what you're saying is that whatever packet size there is for TCP, the IP will encapsulate it with its own header, and then when leaving the interface it is split into multiple packets if needed?
– Myntekt
Jan 19 at 19:41
Yes, nothing specifically to do with TCP. This is an IP function.
– jonathanjo
Jan 19 at 19:42
add a comment |
After the routing decision is made for a given packet, it is scheduled to go out of a particular interface. If the packet is too big for the MTU of the link, it is sent as two or more IP packets containing fragments. The details are in Internet Protocol RFC 760 section 2.2, but in brief the first one has the beginning of the packet including the TCP header, and the later ones are just continuations. The receiver can tell there are more by the "More Fragments" flag in the header, and sees where they go by the Fragment offset.
As the beginning of the IP packet payload is in the first fragment, only the first fragment has the TCP header. The subsequent fragments will just begin with their appropriate part of the payload, probably bytes from the middle of the TCP stream.
This mechanism is IPv4-specific, and isn't directly related to the content of the packet. TCP tries to keep the packets inside the MTU by adjusting the maximum segment size of the TCP stream, but if the MSS is too high, you'll get the fragmentation.
Remember there's also a "Don't Fragment" flag, which if implemented, means instead of forwarding the fragments, the system will drop the packet and send an ICMP error back (unless configured not to).
Remember also that this "do I need to fragment this packet" question happens for every packet going out of every interface. Even if the interface out of a server has a MTU big enough for a given packet, some router along the way might have a much smaller MTU -- this is the "path MTU" issue. Any routing change, such as for load balancing or fault recovery, can change the path MTU. As a consequence of this, it's legitimate for fragments to arrive in the right order, overlap, be partially duplicated.
Finally, don't forget that fragments can be misformed on purpose: such as sending duplicate portions of the data, which can lead to some unpleasant security problems. Consequently many routers and firewalls do a certain amount of reassembly even though strictly speaking they don't this isn't needed to do the router's job -- it could just forward the fragments.
So what you're saying is that whatever packet size there is for TCP, the IP will encapsulate it with its own header, and then when leaving the interface it is split into multiple packets if needed?
– Myntekt
Jan 19 at 19:41
Yes, nothing specifically to do with TCP. This is an IP function.
– jonathanjo
Jan 19 at 19:42
add a comment |
After the routing decision is made for a given packet, it is scheduled to go out of a particular interface. If the packet is too big for the MTU of the link, it is sent as two or more IP packets containing fragments. The details are in Internet Protocol RFC 760 section 2.2, but in brief the first one has the beginning of the packet including the TCP header, and the later ones are just continuations. The receiver can tell there are more by the "More Fragments" flag in the header, and sees where they go by the Fragment offset.
As the beginning of the IP packet payload is in the first fragment, only the first fragment has the TCP header. The subsequent fragments will just begin with their appropriate part of the payload, probably bytes from the middle of the TCP stream.
This mechanism is IPv4-specific, and isn't directly related to the content of the packet. TCP tries to keep the packets inside the MTU by adjusting the maximum segment size of the TCP stream, but if the MSS is too high, you'll get the fragmentation.
Remember there's also a "Don't Fragment" flag, which if implemented, means instead of forwarding the fragments, the system will drop the packet and send an ICMP error back (unless configured not to).
Remember also that this "do I need to fragment this packet" question happens for every packet going out of every interface. Even if the interface out of a server has a MTU big enough for a given packet, some router along the way might have a much smaller MTU -- this is the "path MTU" issue. Any routing change, such as for load balancing or fault recovery, can change the path MTU. As a consequence of this, it's legitimate for fragments to arrive in the right order, overlap, be partially duplicated.
Finally, don't forget that fragments can be misformed on purpose: such as sending duplicate portions of the data, which can lead to some unpleasant security problems. Consequently many routers and firewalls do a certain amount of reassembly even though strictly speaking they don't this isn't needed to do the router's job -- it could just forward the fragments.
After the routing decision is made for a given packet, it is scheduled to go out of a particular interface. If the packet is too big for the MTU of the link, it is sent as two or more IP packets containing fragments. The details are in Internet Protocol RFC 760 section 2.2, but in brief the first one has the beginning of the packet including the TCP header, and the later ones are just continuations. The receiver can tell there are more by the "More Fragments" flag in the header, and sees where they go by the Fragment offset.
As the beginning of the IP packet payload is in the first fragment, only the first fragment has the TCP header. The subsequent fragments will just begin with their appropriate part of the payload, probably bytes from the middle of the TCP stream.
This mechanism is IPv4-specific, and isn't directly related to the content of the packet. TCP tries to keep the packets inside the MTU by adjusting the maximum segment size of the TCP stream, but if the MSS is too high, you'll get the fragmentation.
Remember there's also a "Don't Fragment" flag, which if implemented, means instead of forwarding the fragments, the system will drop the packet and send an ICMP error back (unless configured not to).
Remember also that this "do I need to fragment this packet" question happens for every packet going out of every interface. Even if the interface out of a server has a MTU big enough for a given packet, some router along the way might have a much smaller MTU -- this is the "path MTU" issue. Any routing change, such as for load balancing or fault recovery, can change the path MTU. As a consequence of this, it's legitimate for fragments to arrive in the right order, overlap, be partially duplicated.
Finally, don't forget that fragments can be misformed on purpose: such as sending duplicate portions of the data, which can lead to some unpleasant security problems. Consequently many routers and firewalls do a certain amount of reassembly even though strictly speaking they don't this isn't needed to do the router's job -- it could just forward the fragments.
edited Jan 20 at 11:38
answered Jan 19 at 19:39
jonathanjojonathanjo
11.4k1934
11.4k1934
So what you're saying is that whatever packet size there is for TCP, the IP will encapsulate it with its own header, and then when leaving the interface it is split into multiple packets if needed?
– Myntekt
Jan 19 at 19:41
Yes, nothing specifically to do with TCP. This is an IP function.
– jonathanjo
Jan 19 at 19:42
add a comment |
So what you're saying is that whatever packet size there is for TCP, the IP will encapsulate it with its own header, and then when leaving the interface it is split into multiple packets if needed?
– Myntekt
Jan 19 at 19:41
Yes, nothing specifically to do with TCP. This is an IP function.
– jonathanjo
Jan 19 at 19:42
So what you're saying is that whatever packet size there is for TCP, the IP will encapsulate it with its own header, and then when leaving the interface it is split into multiple packets if needed?
– Myntekt
Jan 19 at 19:41
So what you're saying is that whatever packet size there is for TCP, the IP will encapsulate it with its own header, and then when leaving the interface it is split into multiple packets if needed?
– Myntekt
Jan 19 at 19:41
Yes, nothing specifically to do with TCP. This is an IP function.
– jonathanjo
Jan 19 at 19:42
Yes, nothing specifically to do with TCP. This is an IP function.
– jonathanjo
Jan 19 at 19:42
add a comment |
How is the fragmentation handled here?
We have to distinguish two cases:
Case 1: Layer-2 does not allow a frames of such a length
In this case an IP packet of 2000 bytes size (or whatever size is required) is built and the TCP segment is inserted into that 2000 byte IP packet.
This packet will be fragmented on IP layer (layer-3) so it can be transmitted in fragments of let's say 500 byte size..
This happens completely on IP layer; TCP layer does not know that the IP packet of 2000 bytes size is fragmented.
Case 2: IP packet sizes are restricted
In some cases the sizes of IP packets may be restricted. (As an example there are some CGNATs allowing IP packets of limited size only.
In this case the TCP layer (layer-4) simply cannot send segments of such a long size.
In the first packet of a TCP connection both computers involved in a connection can tell the other computer the maximum size of a TCP segment the computer is able to receive.
If a computer supports only IP packets up to 800 bytes size, it may tell the other computer that TCP segments of up to 700 bytes are supported, so the resulting IP packet will be less than 800 bytes long.
add a comment |
How is the fragmentation handled here?
We have to distinguish two cases:
Case 1: Layer-2 does not allow a frames of such a length
In this case an IP packet of 2000 bytes size (or whatever size is required) is built and the TCP segment is inserted into that 2000 byte IP packet.
This packet will be fragmented on IP layer (layer-3) so it can be transmitted in fragments of let's say 500 byte size..
This happens completely on IP layer; TCP layer does not know that the IP packet of 2000 bytes size is fragmented.
Case 2: IP packet sizes are restricted
In some cases the sizes of IP packets may be restricted. (As an example there are some CGNATs allowing IP packets of limited size only.
In this case the TCP layer (layer-4) simply cannot send segments of such a long size.
In the first packet of a TCP connection both computers involved in a connection can tell the other computer the maximum size of a TCP segment the computer is able to receive.
If a computer supports only IP packets up to 800 bytes size, it may tell the other computer that TCP segments of up to 700 bytes are supported, so the resulting IP packet will be less than 800 bytes long.
add a comment |
How is the fragmentation handled here?
We have to distinguish two cases:
Case 1: Layer-2 does not allow a frames of such a length
In this case an IP packet of 2000 bytes size (or whatever size is required) is built and the TCP segment is inserted into that 2000 byte IP packet.
This packet will be fragmented on IP layer (layer-3) so it can be transmitted in fragments of let's say 500 byte size..
This happens completely on IP layer; TCP layer does not know that the IP packet of 2000 bytes size is fragmented.
Case 2: IP packet sizes are restricted
In some cases the sizes of IP packets may be restricted. (As an example there are some CGNATs allowing IP packets of limited size only.
In this case the TCP layer (layer-4) simply cannot send segments of such a long size.
In the first packet of a TCP connection both computers involved in a connection can tell the other computer the maximum size of a TCP segment the computer is able to receive.
If a computer supports only IP packets up to 800 bytes size, it may tell the other computer that TCP segments of up to 700 bytes are supported, so the resulting IP packet will be less than 800 bytes long.
How is the fragmentation handled here?
We have to distinguish two cases:
Case 1: Layer-2 does not allow a frames of such a length
In this case an IP packet of 2000 bytes size (or whatever size is required) is built and the TCP segment is inserted into that 2000 byte IP packet.
This packet will be fragmented on IP layer (layer-3) so it can be transmitted in fragments of let's say 500 byte size..
This happens completely on IP layer; TCP layer does not know that the IP packet of 2000 bytes size is fragmented.
Case 2: IP packet sizes are restricted
In some cases the sizes of IP packets may be restricted. (As an example there are some CGNATs allowing IP packets of limited size only.
In this case the TCP layer (layer-4) simply cannot send segments of such a long size.
In the first packet of a TCP connection both computers involved in a connection can tell the other computer the maximum size of a TCP segment the computer is able to receive.
If a computer supports only IP packets up to 800 bytes size, it may tell the other computer that TCP segments of up to 700 bytes are supported, so the resulting IP packet will be less than 800 bytes long.
answered Jan 19 at 21:38
Martin RosenauMartin Rosenau
1,03318
1,03318
add a comment |
add a comment |
Thanks for contributing an answer to Network Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f56254%2fhow-does-a-tcp-segment-fit-into-a-smaller-ip-packet%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
The TCP MSS is based on the MTU.
– Ron Maupin♦
Jan 19 at 19:37