Cover the GRE header and payload with the optional checksum
03When C is one, both a two-byte checksum and two-byte Reserved1 field follow the first four bytes.
Separate received input: one payload byte changed while the checksum was retained. The demonstrated verification fails and stops before treating the payload as accepted.
Source for this drawing: RFC 2784 · Read RFC section 2.2 ↗
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.
Checksum presence is selected by C; a checksum is not authentication.
- A compliant implementation MUST accept and process the checksum field when present. The C flag controls presence; a numeric checksum value of zero does not mean the field is absent.
- The checksum uses the one’s-complement sum of 16-bit words across the GRE header and payload, with the checksum field zero during calculation. Odd-length input is zero-padded for the calculation only.
- Reserved1 is present together with the checksum and MUST be transmitted as zero. RFC 2784 does not state the same explicit receiver-ignore rule for Reserved1 as for Reserved0 bits5–12; this guide does not invent one.
- The outer delivery IP header is outside the GRE checksum. A changed payload can fail the illustrated integrity check, but anyone who can rewrite the packet can recalculate this unkeyed checksum.
The worked payload is bytes01 02 03, chosen solely to expose odd-octet arithmetic. It is a byte example rather than a complete IPv4 packet. No IP-header, Ethernet FCS or cryptographic checksum is implied. References: RFC 2784 sections2.5–2.6 and RFC 1071 section1.
Read the RFC section ↗