Standards/Ethernet/IPv4
(→Destination address) |
(→Protocol) |
||
| Line 91: | Line 91: | ||
The most common are: | The most common are: | ||
| − | * [[Standards/Ethernet/UDP|UDP]] | + | * [[Standards/Ethernet/UDP|UDP]]: 17 |
| − | * TCP | + | * TCP: 6 |
=== Header Checksum === | === Header Checksum === | ||
Revision as of 20:18, 26 January 2016
|
The most known Ethernet protocol is Internet Protocol version 4 (IPv4). Its Ethertype is 0800h.
Packet frame
The IPv4 packet header consists of 14 fields, of which 13 are required. The 14th field is optional (red background in table) and aptly named: options. The fields in the header are packed with the most significant byte first (big endian), and for the diagram and discussion, the most significant bits are considered to come first. The most significant bit is numbered 0, so the version field is actually found in the four most significant bits of the first byte, for example.
| byte\bit offset | 0–3 | 4–7 | 8–13 | 14-15 | 16–18 | 19–31 | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Version | Header Length | Differentiated Services Code Point | Explicit Congestion Notification | Total Length | |||||||||||||||||||||||||||
| 4 | Identification | Flags | Fragment Offset | |||||||||||||||||||||||||||||
| 8 | Time to Live | Protocol | Header Checksum | |||||||||||||||||||||||||||||
| 12 | Source IP Address | |||||||||||||||||||||||||||||||
| 16 | Destination IP Address | |||||||||||||||||||||||||||||||
| 20 | Options ( if Header Length > 5 ) | |||||||||||||||||||||||||||||||
| 20 or 48+ |
Data | |||||||||||||||||||||||||||||||
Version
For IPv4, the version field has a value of 4.
Header Length
The Internet Header Length (IHL) tells the number of 32-bit words in the header. The minimum value for this field is 5 (RFC 791).
Total Length
This 16-bit field defines the entire datagram size, including header and data, in bytes. The minimum-length datagram is 20 bytes (20-byte header + 0 bytes data) and the maximum is 65,535 bytes — the maximum value of a 16-bit word. The minimum size datagram that any host is required to be able to handle is 576 bytes, but most modern hosts handle much larger packets.
Identification
This field is an identification field and is primarily used for uniquely identifying fragments of an original IP datagram.
Flags
A three-bit field follows and is used to control or identify fragments. They are (in order, from high order to low order):
- bit 0: Reserved; must be zero.
- bit 1: Don't Fragment (DF)
- bit 2: More Fragments (MF)
If the DF flag is set and fragmentation is required to route the packet then the packet will be dropped. For unfragmented packets, the MF flag is cleared. For fragmented packets, all fragments except the last have the MF flag set. The last fragment will have a non-zero Fragment Offset field, differentiating it from an unfragmented packet.
Fragment Offset
The fragment offset field, measured in units of eight-byte blocks, is 13 bits long and specifies the offset of a particular fragment relative to the beginning of the original unfragmented IP datagram. The first fragment has an offset of zero.
Time to Live
The eight-bit Time To Live (TTL) field helps prevent datagrams from persisting (e.g. going in circles) on an internet. This field limits a datagram's lifetime. It is specified in seconds, but time intervals less than 1 second are rounded up to 1. In latencies typical in practice, it has come to be a hop count field. Each router decrements the TTL field by one. When the TTL field hits zero, the packet is no longer forwarded.
Protocol
This field defines the protocol used in the data portion of the IP datagram. The Internet Assigned Numbers Authority maintains a list of IP protocol numbers which was originally defined in RFC 790.
The most common are:
- UDP: 17
- TCP: 6
Header Checksum
The 16-bit Header Checksum field is used for error-checking of the header. At each hop, the checksum of the header must be compared to the value of this field. If a header checksum is found to be mismatched, then the packet is discarded. Note that errors in the data field are up to the encapsulated protocol to handle — indeed, both UDP and TCP have checksum fields. Since the TTL field is decremented on each hop and fragmentation, it is possible at each hop then at each hop the checksum will have to be recomputed. The method used to compute the checksum is defined within RFC 1071:
- The checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.
In other words:
- all 16-bit words are summed together (with the checksum field set to zero),
- any overflows from the most significant bits are added into the least significant bits,
- The sum is then one's complemented (all bits are inverted) and this final value is inserted as the checksum field.
For example, header 4500.0022.0000.4000.1011.0000.0123.4567.89AB.CDEF gives:
- 4500 + 0022 + 0000 + 4000 + 1011 + 0000 + 0123 + 4567 + 89AB + CDEF = 2.3357
- 2 + 3357 = 3359
- 3359 = 0011.0011.0101.1001, it's 1's complement is 1100.1100.1010.0110 = CCA6
To validate a header's checksum the same algorithm may be used - the checksum of a header which contains a correct checksum field will be a word containing all zeros (value 0).
Source address
An IPv4 address indicating the sender of the packet. Note that this address may be changed in transit by a network address translation device.
Destination address
An IPv4 address indicating the receiver of the packet. Note that this address may be changed in transit by a network address translation device.
