Read the version and reserved-bit rules
02The first four GRE bytes hold flags and version, followed by a two-byte Protocol Type. The checksum flag controls whether four more bytes follow.
Separate header 00 01 08 00 has version1. It is not version0 GRE; this decoder stops rather than treating it as the RFC 2784 layout.
Source for this drawing: RFC 2784 · Read RFC section 2.1 ↗
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.
Version is zero; reserved fields have different sending and receiving rules.
- The C flag is bit 0, the most significant bit: mask 8000 in the first 16-bit word. Version occupies bits 13–15 and MUST be zero for this GRE version.
- Apply verified technical erratum 3719: a base receiver without RFC 1701 support MUST discard nonzero bits 1–4. Bits 5–12 MUST be zero when sent and MUST be ignored on receipt.
- RFC 2890 later restores Key and Sequence flags at bits 2 and 3. The base-only examples here are explicitly distinguished from that updated profile.
- Protocol Type describes the payload using EtherType values. An unlisted type SHOULD be discarded; the bounded teaching receiver supports only the illustrated IPv4 payload.
Normal base bytes are 00 00 08 00. Separate nonconforming-sender example 04 00 08 00 sets reserved bit5 but still has version0: the receiver ignores that bit. These are not sequential mutations of one accepted packet. Field boxes are schematic, not bit-scaled.
Read the RFC section ↗