Pad a short frame without growing its IP packet
02Ethernet requires at least 46 bytes in its data field. Padding fills the unused space around a short IP datagram; it does not become IP data.
Separate damaged input: IP Total Length claims 60, but only 46 data-field bytes are available. The teaching extractor stops before passing an incomplete datagram onward.
Source for this drawing: RFC 894 · Read RFC source: Frame Format (unnumbered) ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
IP Total Length excludes the Ethernet padding.
- RFC 894 says the minimum Ethernet data field is 46 octets and recommends padding with zero octets when necessary. An octet is an 8-bit byte.
- For a 28-byte IP datagram, append 18 zero bytes to reach 46 Ethernet data bytes. The IP Total Length field remains 28 (hexadecimal 001c).
- A receiver can use the IP Total Length to distinguish the datagram from link padding. An incomplete datagram cannot be repaired by treating missing bytes as padding.
The colored strip is proportional to the Ethernet data field, with offsets relative to its start. It excludes Ethernet addresses, type and FCS. The teaching extractor checks selected length/header boundaries; it is not a complete IPv4, checksum or Ethernet FCS validator. The sender padding recommendation does not create a new receiver MUST-reject-nonzero-padding rule.
Read the RFC section ↗