Why does UDP have the field "UDP Length" twice in its packet? Isn't it redundant? If it is required for some kind of error checking, please provide an example.
Your observation is correct. The length field is redundant because both the IP header and the UDP header has a length field. My only guess about the reason for this redundancy is, that it happened because UDP was designed at a time, where it was not yet clear what the IP protocol suite would look like.
All legitimate UDP packets should have a length field matching exactly what could be derived from the length field in the IP header. If you don't do that, you can't know for sure, what the receiver is going to do with the packet.
UDP packets with inconsistent length fields are seen in the wild on the Internet. I guess they are probing for buffer overflows, which might happen if one length field is used to allocate memory and the other length field is used when copying data to the allocated buffer.
In the newer UDP Lite protocol, the length field has been repurposed. The length field in the UDP Lite header does not indicate how much data there is in the packet, but rather how much of it has been covered by the checksum. The length of the data in a UDP Lite packet is always computed from the length field in the IP header. This is the only difference between the UDP and UDP Lite header formats.
From RFC 768:
Length is the length in octets of this user datagram including
this header and the data. (This means the minimum value of the
length is eight.)
The pseudo header conceptually prefixed to the UDP header contains
the source address, the destination address, the protocol, and
the UDP length. This information gives protection against misrouted
datagrams. This checksum procedure is the same as is used in TCP.
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| source address |
+--------+--------+--------+--------+
| destination address |
+--------+--------+--------+--------+
| zero |protocol| UDP length |
+--------+--------+--------+--------+
The REAL answer is that this is a "pseudo header" - that is, it is used for calculating the checksum, but not actually sent. at least that is what I conclude from What is the Significance of Pseudo Header used in UDP/TCP
Related
I have been learning wireshark lately. While inspecting TCP segments, I saw a strange situation, at least for me. There was a mismatching SEQ,ACK numbers. Then I realized that difference between two ACK's same as 1 and half package size. However, as far as I know, ACKs are only growing by the full packet size. So what happened here?
SEQ ACK
1 1
2897 8689
5793 13033 <--
8689 14481
11585
14481
Well, there's not much to go by here, but I'm going to guess that you are capturing packets on the machine sending the large packets, i.e., the packets with 2896 bytes of TCP payload. As such, you are seeing the packets before they are IP-fragmented and actually transmitted out on the wire.
But you can't just send 2896 bytes of data onto the wire; Ethernet links typically impose a 1500 byte MTU (Maximum Transmission Unit), and when you account for IP and TCP header overhead, you usually end up with 1460 bytes of available payload or MSS (Maximum Segment Size). In your case it looks like you're only getting 1448 bytes of available MSS, most likely due to the addition of one or more IP and/or TCP header options.
In any case, the 2896 bytes of payload are going to be fragmented over 2 IP fragments, each containing 1448 bytes of TCP payload. I'm pretty sure that what you're seeing is an ACK from the receiver after having received 1 full segment plus 1 IP fragment from the next segment.
The previous ACK number was 8689, and 8689 + 2896 = 11585. Now add 1/2 of the data segment (2896 / 2 = 1448) and you get 11585 + 1448 = 13033. That's the ACK number you're seeing. Now add the other 1/2 and you get 13033 + 1448 = 14481, which is the ACK number of the next packet.
I hope that makes sense?
For an in depth look at the drawbacks of local packet captures, I direct you to a well-written blog by Jasper Bongertz titled, "The drawbacks of local packet captures".
Since I do not have reputation to comment the answer of Christopher Maynard, I comment it here.
As Christopher stated correctly the MTU (Maximum Transmission Unit) is standard Ethernet networks is 1500Bytes. However, crafting 1460Bytes (1500Bytes - 20Bytes IP Header - 20Bytes TCP Header, ignoring possible TCP options) TCP segments imposes a high load on the network stack since every segment must be handled separately.
As an example, if I want to transmit 1Mb (equals to 1024*1024Bytes = 1048576Bytes) of data, it would result in 1Mb/1460Bytes = 719 segments. In contrast to 1Mb/65525Bytes (theoretical max TCP segment size) = 16 segments. Since the overhead in the Kernel is mostly independent of the segment/packet size, small segments require much more processing.
To counteract this fact, TCP Segmentation Offloading (TSO) was developed. TSO allows the Kernel to craft TCP segments with maximum size and the NIC (Network Interface Card) uses hardware acceleration to split these segments into the separate TCP segments of 1460Bytes. Therefore, no IP fragmentation is required.
I am currently going through my networking slides and was wondering if someone could help me with the concept of fragmentation
so i understand the first part till "108 Bytes" but what I don't understand is this "8 Bytes = 13.5 => 13 * 8
Bytes = 104 Bytes"
what are these extra bytes ?
the rest is clear.
You must fragment the packet payload on eight-byte boundaries. With a 128-byte MTU, the largest payload fragment you can have is 104 bytes, which is smaller than simply subtracting the IP header from the MTU (108 bytes). What the text is telling you that subtracting the packet header size (20 bytes) from the MTU, the next smaller fragment size divisible by eight is 104 bytes.
RFC 791, Internet Protocol has a complete description of how IP fragmentation works:
Fragmentation
Fragmentation of an internet datagram is necessary when it originates
in a local net that allows a large packet size and must traverse a
local net that limits packets to a smaller size to reach its
destination.
An internet datagram can be marked "don't fragment." Any internet
datagram so marked is not to be internet fragmented under any
circumstances. If internet datagram marked don't fragment cannot be
delivered to its destination without fragmenting it, it is to be
discarded instead.
Fragmentation, transmission and reassembly across a local network
which is invisible to the internet protocol module is called intranet
fragmentation and may be used [6].
The internet fragmentation and reassembly procedure needs to be able
to break a datagram into an almost arbitrary number of pieces that can
be later reassembled. The receiver of the fragments uses the
identification field to ensure that fragments of different datagrams
are not mixed. The fragment offset field tells the receiver the
position of a fragment in the original datagram. The fragment offset
and length determine the portion of the original datagram covered by
this fragment. The more-fragments flag indicates (by being reset) the
last fragment. These fields provide sufficient information to
reassemble datagrams.
The identification field is used to distinguish the fragments of one
datagram from those of another. The originating protocol module of an
internet datagram sets the identification field to a value that must
be unique for that source-destination pair and protocol for the time
the datagram will be active in the internet system. The originating
protocol module of a complete datagram sets the more-fragments flag to
zero and the fragment offset to zero.
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. The data of the long datagram is divided
into two portions on a 8 octet (64 bit) boundary (the second portion
might not be an integral multiple of 8 octets, but the first must be).
Call the number of 8 octet blocks in the first portion NFB (for Number
of Fragment Blocks). The first portion of the data is placed in the
first new internet datagram, and the total length field is set to the
length of the first datagram. The more-fragments flag is set to one.
The second portion of the data is placed in the second new internet
datagram, and the total length field is set to the length of the
second datagram. The more-fragments flag carries the same value as
the long datagram. The fragment offset field of the second new
internet datagram is set to the value of that field in the long
datagram plus NFB.
This procedure can be generalized for an n-way split, rather than the
two-way split described.
To assemble the fragments of an internet datagram, an internet
protocol module (for example at a destination host) combines internet
datagrams that all have the same value for the four fields:
identification, source, destination, and protocol. The combination is
done by placing the data portion of each fragment in the relative
position indicated by the fragment offset in that fragment's internet
header. The first fragment will have the fragment offset zero, and
the last fragment will have the more-fragments flag reset to zero.
Per the definition of the Fragment offset field in the IP header:
Fragment offset(13 bits): In case of fragmented IP datagrams, this field contains the offset( in terms of 8 bytes units) from the start of IP datagram. So again, this field is used in reassembly of fragmented IP datagrams.
So even though payload sizes can be whatever, offset values can only be multiple of 8 bytes on IP headers thus payload sizes are 8-byte multiples. The calculation rounds down the IP payload size.
Why do we need the sequence number and the next sequence number field in the TCP header?
Below is a TCP header from a packet captured using wireshark.
First, fields in Wireshark enclosed by [brackets] are computed fields - they're not in the packet. That next sequence number field shown by Wireshark is one such field. Wireshark is computing that by taking the 'sequence number' field and adding it to the payload size of your packet. It's no surprise then that the difference between these two numbers is 1430 - a common TCP payload size.
Sequence numbers in TCP are in units of bytes - they basically say, what byte location in the TCP stream this packet's payload is inserted at.
The 'acknowledged' sequence number shows how many bytes I'm acknowledging as having received.
Since TCP is bidirectional, each end has to declare
Where the bytes its transmitting should go in the stream and
What bytes that you've sent me that I've received.
As such, each TCP packet has two fields that refer to sequence numbers - the 'sequence number' field, and the 'acknowledgment number' field.
Without the 'sequence number' field, the receiving end wouldn't be able to tell if packets were received out of order. Without the 'acknowledgment number' field, the transmitting end wouldn't know if some of his packets had been dropped and the receiver never received them.
Because TCP is a reliable pipe. This means that packets are delivered in sequence (and only once) even though the lower layers don't offer that guarantee. IN order to do this TCP needs housekeeping data, acks, nacks,....
https://en.wikipedia.org/wiki/Transmission_Control_Protocol
The 'next sequence' is an artifact of wireshark, its not actually in the TCP header, ws is just telling you the next packet in its capture file
Suppose I have two hosts, host A and host B, and host A sends a 1500 byte packet to B and there are two routers between them with a MTU of 800 bytes for the first link, and MTU of 500 bytes for the second link between them.
As I understand it the packet will have to be fragmented both times. The packet will have to be fragmented into 3 packets (2 equally sized packets and one smaller one).
Then when we hit this second router we will have each of the first two fragmented packets be fragmented once more. The first two original fragments will produce 1 larger fragment (close to 500 bytes), and one smaller one.
This is where I am confused.
I know that the 'More Fragment' bit should be set to 1 on all of the first 3 fragments except the last indicating that the packets are part of a fragment up to and including the next packet with 'More Fragment' set to 0. However, for the second set of fragments I am not so sure. If this was the first time the packet had been fragmented, the last fragment would have 'More Fragment' of 0, but since this is actually just a fragment somewhere in the middle of the original message, I have a feeling it should be 1.
I am hoping someone with more experience can shed some light on this for me. Is the 'More Fragment' bit used in reassembly? If so I would imagine that when the fragments are fragmented then we do not set the last fragment to 0.
So the algorithm would go:
If fragmenting a packet with 'More Fragment' set to 0,
then set 'More Fragment' to 1 in all fragmented packets except the last.
Else If fragmenting a packet with 'More Fragment' set to 1,
then set 'More Fragment' to 1 in all of the fragmented packets.
Is my assumption here correct?
You are more or less right. Routers besides adding MF (more fragments) flag are doing some more processing:
To fragment/segment a long internet packet, a router (R1 in the figure
below) creates a new IP packet and copies the contents of the IP
header fields from the long packet into the new IP header. The data of
the long packet is then divided into two portions on a 8 byte (64 bit)
boundary, so that the first packet is less than the MTU of the
out-going interface. The more-fragments flag (MF) in the first packet
is set to one (to indicate that more fragments of this packet follow).
The More Flag may already be set in this packet if it has already been
fragmented by another system. This packet is forwarded.
The second created new packet is then processed. The packet header
field is identical to that of the original packet (including the same
value of the packet ID, the total length field, the more-fragments
flag (MF) and the fragment offset field in the original packet). The
packet header field is updated with a new offset field, by adding the
number of payload bytes sent in the first fragment. If this new packet
is larger than the allowed link MTU, the packet is again fragmented.
So in nutshell for already fragmented packets whole IP header is being copied to new packets (smaller fragments of fragment). It means that if IP packet has MF set it will be also copied to last fragmented packet. Thanks to changing offset and packets ID host receiving fragmented packets will be able to reassemble those.
I'm a beginner of TCP/IP suite.
One field of ip header named HEADER CHECKSUM is formed by treating the header as a sequence of 16 bit integers,adding them together using one's complement arithmetic,and then taking the one's complement of the result.
But the ip header also includes TTL field,which may change in the transmission.
Why would it not lead inconsistence between the sender and receiver?
The checksum is recomputed at every hop
As the TTL field is decremented on each hop, a new checksum must be
computed each time. The method used to compute the checksum is defined
by RFC 1071