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
Related
My firewall textbook says: "UDP breaks a message into numbered segments so that it can be transmitted."
My understanding was UDP had no sequence or other numbering scheme? That data was broken into packets and sent out with no ordered reconstruction on the other end, at least on this level. Am I missing something?
The book is just wrong here. The relevant section says:
User Datagram Protocol (UDP)—This protocol is similar to TCP in that it handles the addressing of a message. UDP breaks a message into numbered segments so that it can be transmitted. It then reassembles the message when it reaches the destination computer.
UDP does not include any mechanism to segment or reassemble messages; each message is sent as a single UDP datagram. If you look at the UDP "packet" (technically datagram) structure on page 108, there's no segment number or anything like that.
Mind you, segmentation can happen at other layers, either above or below UDP:
IP packets can be fragmented if they're too big for a network link's MTU (maximum transfer unit). This can happen to IP packets that contain UDP, TCP, or whatever. This is actually relevant for firewalls because creative fragmentation can sometimes be used to bypass packet filtering rules.
Some protocols that run on top of UDP also use something like numbered segments. For example, TFTP (trivial file transfer protocol) breaks files into "blocks", and transmits a block number in the header for each block. (And the receiver responds acknowledging the block number it's received -- it's like a drastically simplified version of TCP.) But this is part of the TFTP protocol, not part of UDP.
QUIC is another example of a protocol that runs over UDP and supports segmentation (and multiple connections, and...), and each packet contains a packet number. But again it's part of the QUIC protocol, not UDP.
packet switching is a protocol, where a message received from tcp layer is divided into packets only at sender machine ip layer and each packet is sent individually on different routes with an identification field set in ip header to help use re-assemble at destination machine.
Where as
fragmentation at ip layer is done on sender machine or any of the, on the way layer 3 device ip layer and fragmentation field is set in ip header to help use re-assemble at destination machine only.
My question:
is my understanding correct?
In packet switching, If message could not be re-assembled due to missing packet at destination, based on identification field, that message is discarded at ip layer of destination machine and tcp layer of sender machine will take care of retransmission of that message, am i correct?
packet switching is a protocol
No. Packet switching is an alternative to circuit switching at the physical layer.
where a message received from tcp layer is divided into packets only at sender machine ip layer and each packet is sent individually on different routes with an identification field set in ip header to help use re-assemble at destination machine.
None of this is correct as a description of packet switching. Packet switching implies the existence of packets, period. It doesn't impose any of these constraints.
Whereas fragmentation at ip layer is done on sender machine or any of the
... intermediate nodes
on the way layer 3 device ip layer
Layer 2
and fragmentation field is set in ip header to help use re-assemble at destination machine only.
My question:
is my understanding correct?
No. You seem to think that packet switching and fragmentation are in some kind of opposition. They aren't. Fragmentation is an extension of packet switching if anything, not an alternative to it.
In packet switching, If message could not be re-assembled due to missing packet at destination, based on identification field, that message is discarded at ip layer of destination machine and tcp layer of sender machine will take care of retransmission of that message, am i correct?
No. Again you're confused about what packet switching is. Your remark applies pretty well to TCP, but that's because of the semantics of TCP, not because of packet switching.
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.
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.