How does the Transport Layer construct the Pseudo-Header for TCP checksum?
THE TCP Psuedo Header needs sender and destination IP Address and protocol type. All of this informations is present in the network layer/IP header. Since the transport layer cannot access the data present in the network layer, how does it construct the Pseudo-Header?
tcp protocol-theory layer4 transport-protocol checksum
add a comment |
THE TCP Psuedo Header needs sender and destination IP Address and protocol type. All of this informations is present in the network layer/IP header. Since the transport layer cannot access the data present in the network layer, how does it construct the Pseudo-Header?
tcp protocol-theory layer4 transport-protocol checksum
Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
– Ron Maupin♦
Dec 25 '18 at 10:00
add a comment |
THE TCP Psuedo Header needs sender and destination IP Address and protocol type. All of this informations is present in the network layer/IP header. Since the transport layer cannot access the data present in the network layer, how does it construct the Pseudo-Header?
tcp protocol-theory layer4 transport-protocol checksum
THE TCP Psuedo Header needs sender and destination IP Address and protocol type. All of this informations is present in the network layer/IP header. Since the transport layer cannot access the data present in the network layer, how does it construct the Pseudo-Header?
tcp protocol-theory layer4 transport-protocol checksum
tcp protocol-theory layer4 transport-protocol checksum
edited Dec 11 '18 at 2:49
Ron Maupin♦
63.9k1367120
63.9k1367120
asked Nov 15 '18 at 10:25
AjiteshAjitesh
162
162
Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
– Ron Maupin♦
Dec 25 '18 at 10:00
add a comment |
Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
– Ron Maupin♦
Dec 25 '18 at 10:00
Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
– Ron Maupin♦
Dec 25 '18 at 10:00
Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
– Ron Maupin♦
Dec 25 '18 at 10:00
add a comment |
2 Answers
2
active
oldest
votes
The pseudo-header doesn't really exist - it is only temporarily created to calculate the checksum.
Within the IP stack, the network layer passes the L3 information upward to the transport layer - likewise, the transport layer passes L3 and L4 information upward to the application layer. Information isn't passed as the original packet but through data fields to/from the API functions. There is no IETF standard for these API functions but most OSes use BSD-style "sockets".
add a comment |
The TCP pseudo header has only information which was used to create the original connection (source and destination IP addresses), a length (which is available to the upper level) and a well-known constant, the protocol (TCP is Internet Protocol number 6.)
From RFC 793, p17.
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
This means that the process of wrapping a sequence of data bytes into a segment and then into a packet uses only information which the upper layer has. Indeed, you will see that for a given connection, all except the length are constant, which means they the checksum up to this point can be computed at connection-open and stored. The computation per packet can start with the pseudo header's length. Some given implementation might actually store the length in that position, if that optimises the code a little.
If you want an up to date standard, look at RFC 8200.
– kasperd
Nov 15 '18 at 13:48
Thanks, yes the IPv6 method is essentially identical, certainly from the conceptual point of view about layers.
– jonathanjo
Nov 15 '18 at 13:53
They are indeed very similar, in particular with the checksum algorithm used by TCP and UDP. That similarity turns out to be convenient when converting packets between IPv4 and IPv6. Biggest differences are that ICMPv6 includes the pseudoheader, which ICMP didn't, and UDP checksums are mandatory on IPv6.
– kasperd
Nov 15 '18 at 14:01
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%2f54727%2fhow-does-the-transport-layer-construct-the-pseudo-header-for-tcp-checksum%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
The pseudo-header doesn't really exist - it is only temporarily created to calculate the checksum.
Within the IP stack, the network layer passes the L3 information upward to the transport layer - likewise, the transport layer passes L3 and L4 information upward to the application layer. Information isn't passed as the original packet but through data fields to/from the API functions. There is no IETF standard for these API functions but most OSes use BSD-style "sockets".
add a comment |
The pseudo-header doesn't really exist - it is only temporarily created to calculate the checksum.
Within the IP stack, the network layer passes the L3 information upward to the transport layer - likewise, the transport layer passes L3 and L4 information upward to the application layer. Information isn't passed as the original packet but through data fields to/from the API functions. There is no IETF standard for these API functions but most OSes use BSD-style "sockets".
add a comment |
The pseudo-header doesn't really exist - it is only temporarily created to calculate the checksum.
Within the IP stack, the network layer passes the L3 information upward to the transport layer - likewise, the transport layer passes L3 and L4 information upward to the application layer. Information isn't passed as the original packet but through data fields to/from the API functions. There is no IETF standard for these API functions but most OSes use BSD-style "sockets".
The pseudo-header doesn't really exist - it is only temporarily created to calculate the checksum.
Within the IP stack, the network layer passes the L3 information upward to the transport layer - likewise, the transport layer passes L3 and L4 information upward to the application layer. Information isn't passed as the original packet but through data fields to/from the API functions. There is no IETF standard for these API functions but most OSes use BSD-style "sockets".
answered Nov 15 '18 at 10:37
Zac67Zac67
27.7k21456
27.7k21456
add a comment |
add a comment |
The TCP pseudo header has only information which was used to create the original connection (source and destination IP addresses), a length (which is available to the upper level) and a well-known constant, the protocol (TCP is Internet Protocol number 6.)
From RFC 793, p17.
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
This means that the process of wrapping a sequence of data bytes into a segment and then into a packet uses only information which the upper layer has. Indeed, you will see that for a given connection, all except the length are constant, which means they the checksum up to this point can be computed at connection-open and stored. The computation per packet can start with the pseudo header's length. Some given implementation might actually store the length in that position, if that optimises the code a little.
If you want an up to date standard, look at RFC 8200.
– kasperd
Nov 15 '18 at 13:48
Thanks, yes the IPv6 method is essentially identical, certainly from the conceptual point of view about layers.
– jonathanjo
Nov 15 '18 at 13:53
They are indeed very similar, in particular with the checksum algorithm used by TCP and UDP. That similarity turns out to be convenient when converting packets between IPv4 and IPv6. Biggest differences are that ICMPv6 includes the pseudoheader, which ICMP didn't, and UDP checksums are mandatory on IPv6.
– kasperd
Nov 15 '18 at 14:01
add a comment |
The TCP pseudo header has only information which was used to create the original connection (source and destination IP addresses), a length (which is available to the upper level) and a well-known constant, the protocol (TCP is Internet Protocol number 6.)
From RFC 793, p17.
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
This means that the process of wrapping a sequence of data bytes into a segment and then into a packet uses only information which the upper layer has. Indeed, you will see that for a given connection, all except the length are constant, which means they the checksum up to this point can be computed at connection-open and stored. The computation per packet can start with the pseudo header's length. Some given implementation might actually store the length in that position, if that optimises the code a little.
If you want an up to date standard, look at RFC 8200.
– kasperd
Nov 15 '18 at 13:48
Thanks, yes the IPv6 method is essentially identical, certainly from the conceptual point of view about layers.
– jonathanjo
Nov 15 '18 at 13:53
They are indeed very similar, in particular with the checksum algorithm used by TCP and UDP. That similarity turns out to be convenient when converting packets between IPv4 and IPv6. Biggest differences are that ICMPv6 includes the pseudoheader, which ICMP didn't, and UDP checksums are mandatory on IPv6.
– kasperd
Nov 15 '18 at 14:01
add a comment |
The TCP pseudo header has only information which was used to create the original connection (source and destination IP addresses), a length (which is available to the upper level) and a well-known constant, the protocol (TCP is Internet Protocol number 6.)
From RFC 793, p17.
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
This means that the process of wrapping a sequence of data bytes into a segment and then into a packet uses only information which the upper layer has. Indeed, you will see that for a given connection, all except the length are constant, which means they the checksum up to this point can be computed at connection-open and stored. The computation per packet can start with the pseudo header's length. Some given implementation might actually store the length in that position, if that optimises the code a little.
The TCP pseudo header has only information which was used to create the original connection (source and destination IP addresses), a length (which is available to the upper level) and a well-known constant, the protocol (TCP is Internet Protocol number 6.)
From RFC 793, p17.
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| zero | PTCL | TCP Length |
+--------+--------+--------+--------+
This means that the process of wrapping a sequence of data bytes into a segment and then into a packet uses only information which the upper layer has. Indeed, you will see that for a given connection, all except the length are constant, which means they the checksum up to this point can be computed at connection-open and stored. The computation per packet can start with the pseudo header's length. Some given implementation might actually store the length in that position, if that optimises the code a little.
edited Nov 15 '18 at 10:45
answered Nov 15 '18 at 10:34
jonathanjojonathanjo
11.3k1934
11.3k1934
If you want an up to date standard, look at RFC 8200.
– kasperd
Nov 15 '18 at 13:48
Thanks, yes the IPv6 method is essentially identical, certainly from the conceptual point of view about layers.
– jonathanjo
Nov 15 '18 at 13:53
They are indeed very similar, in particular with the checksum algorithm used by TCP and UDP. That similarity turns out to be convenient when converting packets between IPv4 and IPv6. Biggest differences are that ICMPv6 includes the pseudoheader, which ICMP didn't, and UDP checksums are mandatory on IPv6.
– kasperd
Nov 15 '18 at 14:01
add a comment |
If you want an up to date standard, look at RFC 8200.
– kasperd
Nov 15 '18 at 13:48
Thanks, yes the IPv6 method is essentially identical, certainly from the conceptual point of view about layers.
– jonathanjo
Nov 15 '18 at 13:53
They are indeed very similar, in particular with the checksum algorithm used by TCP and UDP. That similarity turns out to be convenient when converting packets between IPv4 and IPv6. Biggest differences are that ICMPv6 includes the pseudoheader, which ICMP didn't, and UDP checksums are mandatory on IPv6.
– kasperd
Nov 15 '18 at 14:01
If you want an up to date standard, look at RFC 8200.
– kasperd
Nov 15 '18 at 13:48
If you want an up to date standard, look at RFC 8200.
– kasperd
Nov 15 '18 at 13:48
Thanks, yes the IPv6 method is essentially identical, certainly from the conceptual point of view about layers.
– jonathanjo
Nov 15 '18 at 13:53
Thanks, yes the IPv6 method is essentially identical, certainly from the conceptual point of view about layers.
– jonathanjo
Nov 15 '18 at 13:53
They are indeed very similar, in particular with the checksum algorithm used by TCP and UDP. That similarity turns out to be convenient when converting packets between IPv4 and IPv6. Biggest differences are that ICMPv6 includes the pseudoheader, which ICMP didn't, and UDP checksums are mandatory on IPv6.
– kasperd
Nov 15 '18 at 14:01
They are indeed very similar, in particular with the checksum algorithm used by TCP and UDP. That similarity turns out to be convenient when converting packets between IPv4 and IPv6. Biggest differences are that ICMPv6 includes the pseudoheader, which ICMP didn't, and UDP checksums are mandatory on IPv6.
– kasperd
Nov 15 '18 at 14:01
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%2f54727%2fhow-does-the-transport-layer-construct-the-pseudo-header-for-tcp-checksum%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
Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
– Ron Maupin♦
Dec 25 '18 at 10:00