I know the pseudo header is used to compute the checksum of UDP.But I don't know why.
The reason is that the checksum has to be in the UDP packet before it's given to the IP layer (which adds its own IP header). The pseudo header contains only a few parts of the information that would be in the IP header, and calculates the checksum out of these parts and the UDP content.
After the checksum is calculated, the pseudo header is discarded, it is not transferred!
The client then receives the full IP packet and can validate the checksum with the UDP packet contents and the full IP header.
Related
What happen when ICMP is disabled in an router and when packet size greater than MTU how the router fragments that packet?Will TCP header be present in IP fragmented packets?
I don't test this scenario but ... I think that if the IP fragmentation is enabled, your IP packet data part will be fragmented and transferred independently because the fragmentation was used at L3 layer. Without ICMP, the sending computer don't know that the packet size is bigger than the allowed network MTU and it cannot send new fragmented data at L4 layer (TCP header will be presented in each packet). But we are fragmenting on L3 layer and we have to use fragment offset field. I think that the TCP header will be presented only in one packet, followed by fragmented TCP data part.
Try to make an experiment to test this behavior.
So I have trouble finding a source that describes whether the TCP Packet is the payload of the IP Datagram or vice versa. I imagine the TCP Packet must be the payload because presumably the router can divide the IP Datagram therefore splitting up the TCP Packet and then the final router would have to reassamble them. Am I right?
If by "payload" you're referring to the data that comes after an IP header, then TCP is the "payload" of an IP packet when receiving data, since it's an upper level protocol.
The proper term for networking is actually encapsulation though.
It basically works by adding on progressive layers of protocols as information travels down from the application to the wire. After transmission, the packets are re-assembled and then the packets are error checked, the headers are stripped off, and what you are referring to as the "payload" becomes the next chunk of information that is checked. Once all of the outer protocol layers are stripped off the server/client has the information that directly corresponds to what the application sent.
Tcp\IP are two important proctocols. Tcp is connection oriented, while IP is a connection-less protocol. IP stands for a logical address, which works as packet address. The source packet has destination address for its destination. Tcp works with this logical address and helps the packets to reach their destinations, and provides acknowledgement when packet reached to its destination.
What is the need for having checksum at various layers ? For eg, there is a checksum in TCP layer and again in IP layer and also Ethernet layer has it.
Is not it sufficient to have checksum at one layer ?
All three layers are needed, for multiple reasons:
IP does not always run over ethernet (imagine IP over RS-232 serial, something every Cisco and Unix box can do)
IP does not checksum the data
TCP packets can be reassembled incorrectly from IP packets and fragments that each have perfect checksums
Even if reassembled correctly, software or other errors could be introduced in the layers between IP and TCP
Even if all software functions correctly, and TCP/IP is over ethernet, the limited size of the checksums can be accidently correct (and will be at some point, given enough packets) in the face of persistent errors, so having more than one checksum is helpful.
Every time a new header is introduced there is more to checksum, and the new layer can't see the header bits of the layer below.
Ethernet checksum is a hop to hop checksum - meaning that it is recomputed everytime the Ethernet header fields change. TCP/UDP checksum is a end-to-end checksum meaning it is computed by the sender and verified by the receiver. TCP/UDP checksums cover the entire segment. IP checksum covers only the header. Ethernet CRC covers the entire frame.
The designers of IPv6 decided it's not necessary at all those layers and removed it in favor of checksums at other layers (such as those you mentioned).
I am testing a network device driver's ability to cope with corrupted packets. The specific case I want to test is a when a large TCP packet is fragmented along the path because of smaller MTU in the way.
What most interests me about the IP Fragmentation of the large TCP packet is, is the protocol attribute of the IP Fragment packet set to TCP for each packet, or just the first fragment?
The protocol field will be set to TCP (6) for each fragment.
From RFC 791 - Internet Protocol
To fragment a long internet datagram,
an internet protocol module (for
example, in a gateway), creates two
new internet datagrams and copies the
contents of the internet header fields
from the long datagram into both new
internet headers. ... This procedure
can be generalized for an n-way split,
rather than the two-way split
described.
Protocol is part of the header and will consequently be copied into each of the fragments.
IP Fragmentation is a layer-3 activity, while the packet will be marked TCP, the intermediate fragments will not be usable by TCP. The TCP layer will have to wait for a re-assembly of the actual IP packet (unfragmented) before it can process it.
Wikipedia IP Fragmentation reference.
Path MTU-Discovery will usually update the source MTU and TCP packets (actually segments) will be sent with sizes limited to not cause fragmentation on the way
Why is the Pseudo header prepended to the UDP datagram for the computation of the UDP checksum? What's the rational behind this?
The nearest you will get to an answer "straight from the horse's mouth", is from David P. Reed at the following link.
http://www.postel.org/pipermail/end2end-interest/2005-February/004616.html
The short version of the answer is, "the pseudo header exists for historical reasons".
Originally, TCP/IP was a single monolithic protocol (called just TCP). When they decided to split it up into TCP and IP (and others), they didn't separate the two all that cleanly: the IP addresses were still thought of as part of TCP, but they were just "inherited" from the IP layer rather than repeated in the TCP header. The reason why the TCP checksum operates over parts of the IP header (including the IP addresses) is because they intended to use cryptography to encrypt and authenticate the TCP payload, and they wanted the IP addresses and other TCP parameters in the pseudo header to be protected by the authentication code. That would make it infeasible for a man in the middle to tamper with the IP source and destination addresses: intermediate routers wouldn't notice the tampering, but the TCP end-point would when it attempted to verify the signature.
For various reasons, none of that grand cryptographic plan came to pass, but the TCP checksum which took its place still operates over the pseudo header as though it were a useful thing to do. Yes, it gives you a teensy bit of extra protection against random errors, but that's not why it exists. Frankly, we'd be better off without it: the coupling between TCP and IP means that you have to redefine TCP when you change IP. Thus, the definition of IPv6 includes a new definition for the TCP and UDP pseudo header (see RFC 2460, s8.1). Why the IPv6 designers chose to perpetuate this coupling rather than take the chance to abolish it is beyond me.
From the TCP or UDP point of view, the packet does not contain IP addresses. (IP being the layer beneath them.)
Thus, to do a proper checksum, a "pseudo header" is included. It's "pseudo", because it is not actaully part of the UDP datagram. It contains the most important parts of the IP header, that is, source and destination address, protocol number and data length.
This is to ensure that the UDP checksum takes into account these fields.
When these protocols were being designed, a serious concern of theirs was a host receiving a packet thinking it was theirs when it was not. If a few bits were flipped in the IP header during transit and a packet changed course (but the IP checksum was still correct), the TCP/UDP stack of the redirected receiver can still know to reject the packet.
Though the pseudo-header broke the separation of layers idiom, it was deemed acceptable for the increased reliability.
"The purpose of using a pseudo-header is to verify that the UDP
datagram has reached its correct destination. The key to
understanding the pseudo-header lies in realizing that the correct
destination consists of a specific machine and a specific protocol
port within that machine. The UDP header itself specifies only the
protocol port number. Thus, to verify the destination, UDP on the
sending machine computes a checksum that covers the destination IP
address as well as the UDP datagram. The pseudo-header is not
transmitted with the UDP datagram, nor is it included in the length."
E. Comer - Internetworking with TCP/IP 4th edition.
Pseudo IP header contains the source IP, destination IP, protocol and Total length fields. Now, by including these fields in TCP checksum, we are verifying the checksum for these fields both at Network layer and Transport layer, thus doing a double check to ensure that the data is delivered to the correct host.