Visual RFC.
ALL RFCs / RFC 826
Read the RFC ↗
RFC 826 / PROTOCOL MECHANISMS

Learn from the sender mapping

04

The original receive algorithm merges sender information into an existing table before examining the request opcode.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

RFC 826 · Packet ReceptionEXAMPLE
3 / 3
Learn from the sender mappingThe original receive algorithm merges sender information into an existing table before examining the request opcode.Translation table192.0.2.1 → MAC AIncoming sender: 192.0.2.1 → MAC Bmerge sender mapping192.0.2.1 → MAC BThe changed entry has no cryptographic ownership proof
03
The entry changes; the base protocol has not cryptographically proven ownership.

The entry changes; the base protocol has not cryptographically proven ownership.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

A matching existing sender entry can be updated from incoming information.

  • A matching existing sender entry can be updated from incoming information.
  • An address mapping is not an authenticated identity assertion; forged traffic can poison it.
DETAILS

The drawing is a simplified worked example. Follow the linked RFC and its updates for implementation requirements.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. Resolve the next hop on a link
  2. Broadcast a question and receive a reply
  3. Read the variable-address packet
  4. Learn from the sender mapping
  5. Probe before claiming an IPv4 address

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗