WEB / WEB-02.01

From bytes to the local network

HTTP data is not one packet. Separate byte stream, TCP segment, IP packet and Ethernet frame using a first-neighbor example.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Known cache · IPv4

Stream ready; no frame yet
AB + CDEF gives the same ABCDEF bytes. Remote IP is 198.51.100.200; not every TCP segment is drawn.
Host · eth-demo
ABCDEF · IP target 198.51.100.200
Local neighbor context
192.0.2.1 → 02:00:00:00:00:01 · known
First-hop neighbor
No data frame received
Local next-hop lookup
The selected route identifies next hop 192.0.2.1. Cache lookup is local; it sends no packet.
Host · eth-demo
Next hop 192.0.2.1 · mapping available
Local neighbor context
192.0.2.1 → 02:00:00:00:00:01 · known
First-hop neighbor
No data frame received
Ethernet header built locally
The artifact’s 14-byte header summary uses gateway destination MAC, host source MAC and EtherType 0x0800. Remote IP is unchanged.
Host · eth-demo
MAC dst …:01 · src …:10 · IPv4 dst 198.51.100.200
Local neighbor context
No new ARP needed
First-hop neighbor
No data frame received
First hop received the frame
Neighbor delivery completed. This is only the first Ethernet hop, not evidence of remote HTTP response or TLS identity.
Host · eth-demo
Sent summary · remote IP preserved
Local neighbor context
Mapping used
First-hop neighbor
IPv4 frame received · IP dst 198.51.100.200

Unknown → ARP → known

No IPv4 neighbor mapping
The gateway next hop is selected but its MAC is unknown. The remote server’s MAC is not requested.
Host · eth-demo
Next hop 192.0.2.1 · data waiting
Local neighbor context
192.0.2.1 · unknown
First-hop neighbor
No ARP or data received
ARP request reached the first hop
The ARP request asks about gateway IP 192.0.2.1. Only the relevant neighbor of local broadcast delivery is drawn; the real broadcast has link scope.
Host · eth-demo
Data frame waits for mapping
Local neighbor context
192.0.2.1 · unknown
First-hop neighbor
ARP request received · target IP 192.0.2.1
ARP reply reached the host
The reply’s mapping is now available in host context. This selected normal reply is not presented as identity authentication.
Host · eth-demo
Reply received · next-hop MAC …:01
Local neighbor context
192.0.2.1 → 02:00:00:00:00:01 · known
First-hop neighbor
ARP request processed
Data header ready locally
The mapping is used to build the Ethernet header carrying IPv4. Local preparation is not another network message.
Host · eth-demo
Frame dst MAC …:01 · IP dst 198.51.100.200
Local neighbor context
Mapping known · ready for use
First-hop neighbor
ARP request processed
Data frame reached the neighbor
First-hop data delivery completed after resolution. The full path to the remote endpoint is not drawn.
Host · eth-demo
IPv4 frame summary sent
Local neighbor context
Mapping used
First-hop neighbor
Data frame received · remote IP 198.51.100.200

No observed reply · no delivery

Mapping unknown
The next-hop MAC is unknown in this fixture. Resolution has not produced a result.
Host · eth-demo
Data waiting · next hop 192.0.2.1
Local neighbor context
192.0.2.1 · unknown
First-hop neighbor
No data received
ARP query arrived
A normal request summary reached the link neighbor. A request is not evidence of a reply.
Host · eth-demo
Data waits for mapping
Local neighbor context
192.0.2.1 · unknown
First-hop neighbor
ARP request received · no data received
No resolution result
No reply is present in the selected observation window. Retry counts/error codes are omitted; this observation alone does not identify the cause.
Host · eth-demo
Data delivery did not complete
Local neighbor context
Unknown · cause undetermined
First-hop neighbor
ARP request received · no data received

IPv6 · ND instead of ARP

IPv6 next-hop mapping unknown
Remote destination is 2001:db8:2::20; selected next hop is 2001:db8:1::1. Full route/prefix discovery is omitted.
Host · eth-demo
IPv6 dst 2001:db8:2::20 · data waiting
Local neighbor context
2001:db8:1::1 · unknown
First-hop neighbor
No NS or data received
Neighbor Solicitation arrived
ICMPv6 NS is used for on-link resolution. The relevant multicast recipient is drawn; this is not IPv4 ARP.
Host · eth-demo
Data waits for ND result
Local neighbor context
2001:db8:1::1 · unknown
First-hop neighbor
NS received · target 2001:db8:1::1
Neighbor Advertisement arrived
The selected normal NA supplied a mapping to the host. Known is a teaching label rather than the entire OS neighbor state machine.
Host · eth-demo
NA received · next-hop MAC …:01
Local neighbor context
2001:db8:1::1 → 02:00:00:00:00:01 · known
First-hop neighbor
NS processed
IPv6 frame prepared locally
The next-hop MAC is used and the remote IPv6 destination preserved. This branch supplies no header bytes.
Host · eth-demo
Dst MAC …:01 · IPv6 dst 2001:db8:2::20
Local neighbor context
Mapping available
First-hop neighbor
NS processed
IPv6 first-hop delivery complete
The neighbor received the frame carrying IPv6; remote application outcome is outside this scene.
Host · eth-demo
IPv6 frame summary sent
Local neighbor context
Mapping used
First-hop neighbor
IPv6 frame received · dst 2001:db8:2::20

ACTORS · STATE · DATA FLOW

A byte boundary is not a message boundary

These protocols treat a byte as an eight-bit octet. ABCDEF takes six UTF-8 octets; other Unicode characters can take more. Sending one application message does not mean the transport preserves that boundary. TCP offers an ordered byte stream; sender writes and receiver reads may use different chunks.

Suppose the application writes AB then CDEF. The peer might read A, BCD and EF; concatenation still produces ABCDEF. These are illustrative possibilities, not measured segments. HTTP defines its message framing and TLS its records. A TCP read is not an HTTP-response boundary; a buffer can hold incomplete or multiple messages.

Stream → segment → packet → frame

TCP segments convey portions of the stream within IP datagrams. An Ethernet frame carries the IP packet as payload. Headers serve different layers: TCP ports/sequences, IP addresses, Ethernet MAC addresses. Naming every unit “packet” can hide which boundary is being examined; label the layer in an artifact.

We use Ethernet unicast IPv4. Other transports need not offer streams: UDP preserves datagram boundaries. Wi-Fi link framing differs from Ethernet. An Ethernet-like interface view does not prove a capture contains exact physical wire bytes; capture location and OS/offload processing matter.

Interface and local delivery

Our host uses 192.0.2.10 on eth-demo with MAC 02:00:00:00:00:10. The next hop toward remote 198.51.100.200 is gateway 192.0.2.1. The first Ethernet frame addresses the gateway MAC, not the remote server MAC; its IP destination still identifies the remote endpoint.

MAC supports local-link delivery, not permanent Internet user identity. It belongs to an interface; devices may have several interfaces and software may change addresses. Our 02-prefixed values are locally administered unicast teaching addresses. Loopback and other links need not use this Ethernet-header model.

Which IPv4 address does ARP resolve?

Routing determines the next-hop IP and interface first. On Ethernet, ARP can resolve an unknown IPv4 neighbor’s MAC. The question here concerns 192.0.2.1, not 198.51.100.200. Sender IP/MAC and target IP fields make that distinction. An appropriate reply provides a usable neighbor mapping.

A usable cached mapping avoids a fresh ARP request for each frame. Unresolved neighbors do not count as delivered data: the OS handles queuing, retries and failure. A local reply authenticates neither the remote HTTP server nor its TLS identity. OS cache-state labels differ; known/unknown in the fixture are teaching outcomes only.

The scope of IPv6 Neighbor Discovery

IPv6 does not use ARP for this Ethernet communication. ICMPv6 Neighbor Discovery covers address resolution, router/prefix discovery and neighbor reachability. Address resolution uses Neighbor Solicitation/Advertisement for an on-link neighbor. A remote destination still needs the first-hop neighbor’s link-layer address, not all MACs along the path.

2001:db8:1::10 and 2001:db8:1::1 are documentation addresses. Our ND summary shows names and mapping, not complete ICMPv6 headers, checksums or multicast packet bytes. ARP and ND can satisfy related needs but have different protocols, messages and security conditions.

Read every scenario without motion

Write chunks

A byte stream is not a message
Joining write chunks AB and CDEF or read chunks A, BCD and EF produces the same ABCDEF byte stream. Those chunk boundaries do not have to be application-message boundaries.
Stream chunks
Chunks: AB,CDEF
Message parser
Buffer empty
Application boundary
Message incomplete
The first chunk entered the buffer
The first AB chunk was appended to parser state. The synthetic stream contains no HTTP message grammar; there is no basis to call this chunk a complete HTTP request.
Stream chunks
Chunks: AB,CDEF
Message parser
Buffer=AB
Application boundary
Message incomplete
Premature completion was stopped
The application does not infer message completion from a returned read call. Protocol framing is separately required; fragmentation alone is not a security incident.
Stream chunks
Chunks: AB,CDEF
Message parser
Buffer=AB
Application boundary
Message boundary unknown
Remaining chunks were accumulated
The parser appends remaining chunks in order: CDEF. Buffering preserves byte order; this is local memory state, not another network-packet representation.
Stream chunks
Chunks: AB,CDEF
Message parser
Buffer=ABCDEF
Application boundary
Message boundary unknown
The concatenation invariant held
expectedConcatenation=ABCDEF is identical across the two chunk arrangements. The comparison checks data order, not an application grammar or complete HTTP framing.
Stream chunks
Concat=ABCDEF
Message parser
Buffer=ABCDEF
Application boundary
Message boundary unknown
The result preserved layer boundaries
The identical buffer passes the ordinary stream check. Message acceptance still needs grammar/framing; byte equality establishes neither authorization nor TLS identity.
Stream chunks
Concat=ABCDEF
Message parser
Buffer=ABCDEF
Application boundary
Bytes agree; UNKNOWN: message boundary

Read chunks

A byte stream is not a message
Joining write chunks AB and CDEF or read chunks A, BCD and EF produces the same ABCDEF byte stream. Those chunk boundaries do not have to be application-message boundaries.
Stream chunks
Chunks: A,BCD,EF
Message parser
Buffer empty
Application boundary
Message incomplete
The first chunk entered the buffer
The first A chunk was appended to parser state. The synthetic stream contains no HTTP message grammar; there is no basis to call this chunk a complete HTTP request.
Stream chunks
Chunks: A,BCD,EF
Message parser
Buffer=A
Application boundary
Message incomplete
Premature completion was stopped
The application does not infer message completion from a returned read call. Protocol framing is separately required; fragmentation alone is not a security incident.
Stream chunks
Chunks: A,BCD,EF
Message parser
Buffer=A
Application boundary
Message boundary unknown
Remaining chunks were accumulated
The parser appends remaining chunks in order: BCD, EF. Buffering preserves byte order; this is local memory state, not another network-packet representation.
Stream chunks
Chunks: A,BCD,EF
Message parser
Buffer=ABCDEF
Application boundary
Message boundary unknown
The concatenation invariant held
expectedConcatenation=ABCDEF is identical across the two chunk arrangements. The comparison checks data order, not an application grammar or complete HTTP framing.
Stream chunks
Concat=ABCDEF
Message parser
Buffer=ABCDEF
Application boundary
Message boundary unknown
The result preserved layer boundaries
The identical buffer passes the ordinary stream check. Message acceptance still needs grammar/framing; byte equality establishes neither authorization nor TLS identity.
Stream chunks
Concat=ABCDEF
Message parser
Buffer=ABCDEF
Application boundary
Bytes agree; UNKNOWN: message boundary

ASSUMPTION · BOUNDARY · CONTROL

Misreading stream boundaries

An application completes messages using its protocol grammar. Treating each read as a complete HTTP message can process incomplete data or include later-message bytes. This is a parser/state assumption, not proof that every fragmentation is an incident.

Apply protocol framing and buffer state correctly. Different chunks preserving the same stream are a benign baseline. Security impact needs a condition where incorrect parsing harms permission, integrity or resource use.

Treating a local mapping as identity proof

ARP/ND mapping supports next-hop delivery. Taking it as application identity or entitlement merges trust layers. Basic ARP does not cryptographically authenticate an application identity; IPv6 ND also has security conditions.

The relevant boundary is local-link access and mapping trust. Link controls, network isolation and TLS peer validation have different jobs. A changed MAC is not inherently malicious; interface replacement or virtualization can explain it.

A wrong interface changes the scope

Correctly formatted data on the wrong interface or next hop can fail to reach the intended destination. Confidentiality or availability risks depend on topology and upper-layer protection.

Keep route, interface and mapping authority consistent. This lesson explains normal lookup and delivery boundaries, without network spoofing or intervention steps.

Read every scenario without motion

Known next hop

Offsets belong to the right layer
Hex 0200000000010200000000100800 is only a 14-byte Ethernet II header. Offsets 0/6/12 identify destination MAC, source MAC and EtherType.
Header evidence
dst MAC …01 / EtherType 0800
Mapping evidence
Mapping unread
Layer review
No conclusion
Next-hop mapping was read separately
IPv4 neighbor 192.0.2.1 → 02:00:00:00:00:01 is supplied with resolution=ARP. teachingState=known is not an OS state name.
Header evidence
dst MAC …01 / EtherType 0800
Mapping evidence
192.0.2.1 → …01 / ARP
Layer review
No conclusion
Remote IP is not the local MAC
payloadSummary supplies destinationIp=198.51.100.200 and nextHopIp=192.0.2.1. The Ethernet destination belongs to the next hop, not proof of the remote application endpoint’s identity.
Header evidence
dst MAC …01 / EtherType 0800
Mapping evidence
192.0.2.1 → …01 / ARP
Layer review
IP=remote / MAC=local hop
IPv6 uses different resolution
The artifact supplies the 2001:db8:1::1 mapping as ICMPv6 Neighbor Discovery. Expecting an ARP event for that branch turns the wrong protocol’s absence into an alarm.
Header evidence
dst MAC …01 / EtherType 0800
Mapping evidence
IPv6: ND / IPv4: ARP
Layer review
IP=remote / MAC=local hop
Header evidence stayed bounded
Payload bytes, checksum/FCS and padding are absent from this header-only artifact. 0800 indicates IPv4 payload type, not HTTP method, TLS peer or service delivery.
Header evidence
Header only / delivery unknown
Mapping evidence
IPv6: ND / IPv4: ARP
Layer review
IP=remote / MAC=local hop
Separate consistency from delivery
destinationMac agrees with the next-hop MAC. This bounded header/mapping check does not prove NIC transmission, routed delivery or application acceptance.
Header evidence
Header only / delivery unknown
Mapping evidence
IPv6: ND / IPv4: ARP
Layer review
Header/mapping agree; delivery unknown

Neighbor absent

Offsets belong to the right layer
Hex 0200000000010200000000100800 is only a 14-byte Ethernet II header. Offsets 0/6/12 identify destination MAC, source MAC and EtherType.
Header evidence
dst MAC …01 / EtherType 0800
Mapping evidence
Mapping unread
Layer review
No conclusion
Next-hop mapping was read separately
The review copy lacks a neighbor record. A MAC in the header does not show how or when its mapping was produced.
Header evidence
dst MAC …01 / EtherType 0800
Mapping evidence
Neighbor evidence missing
Layer review
No conclusion
Remote IP is not the local MAC
payloadSummary supplies destinationIp=198.51.100.200 and nextHopIp=192.0.2.1. The Ethernet destination belongs to the next hop, not proof of the remote application endpoint’s identity.
Header evidence
dst MAC …01 / EtherType 0800
Mapping evidence
Neighbor evidence missing
Layer review
IP=remote / MAC=local hop
IPv6 uses different resolution
IPv6 uses ICMPv6 Neighbor Discovery rather than ARP for this need. That protocol distinction does not fill the missing neighbor record in this review copy. The OS neighbor information for the same interface and observation window is still required.
Header evidence
dst MAC …01 / EtherType 0800
Mapping evidence
Neighbor evidence missing
Layer review
IP=remote / MAC=local hop
Header evidence stayed bounded
Payload bytes, checksum/FCS and padding are absent from this header-only artifact. 0800 indicates IPv4 payload type, not HTTP method, TLS peer or service delivery.
Header evidence
Header only / delivery unknown
Mapping evidence
Neighbor evidence missing
Layer review
IP=remote / MAC=local hop
Separate consistency from delivery
Header fields are known; neighbor-resolution coverage is missing. No failed resolution or permission denial is claimed; mapping evidence from the same interface is needed.
Header evidence
Header only / delivery unknown
Mapping evidence
Neighbor evidence missing
Layer review
UNKNOWN: resolution

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Read a header at its own layer

The hex artifact is only a 14-byte Ethernet II header: six destination-MAC bytes, six source-MAC bytes, then two EtherType bytes. 0800 identifies IPv4 payload. Source/destination IP in the payload summary belong to another layer. This header does not establish HTTP method, TLS identity or permission.

Real captures require known interface, link type, timestamp and scope. Our header-only artifact validates no checksum, FCS, padding or complete frame length. Do not label it a valid wire packet.

Known, unknown and another protocol

Normal IPv4 has a usable gateway mapping. Unknown mapping needs resolution before data delivery; absence of HTTP response is not automatically authorization denial. IPv6 uses ND and does not require an ARP event.

Missing telemetry differs from failed resolution. Correlate OS neighbor, route and interface observations. Refresh or interface changes can be benign; one MAC change is not a finding.

Explainable consistency checks

Require destination MAC to match the next hop while IP destination remains the remote endpoint. Header offsets total 14 bytes. Concatenated write/read chunks preserve the same stream. These checks do not prove NIC or network delivery.

Keep link, transport and message boundaries distinct. Resolution advances only once mapping exists; unresolved branches leave receiver data unchanged. Do not impose IPv4 fields on the IPv6 path.

An application consuming socket reads must preserve byte order rather than treating every read result as a new complete message. Here writes AB + CDEF and reads A + BCD + EF produce the same ABCDEF stream; read-call boundaries are not message delimiters. The consumer must apply its upper-layer protocol’s completion rule and avoid presenting incomplete bytes as a successful HTTP body or application result. Varying ordinary chunk boundaries while checking the same reconstructed stream provides a small, explainable verification of that distinction.

NOW APPLY IT TO THE CASE

Do stream chunks or a MAC establish application trust?

eth-demo uses its local gateway MAC when sending to a remote IP. Writing a stream as AB and CDEF does not mean it will be read in those groups. Neighbor addressing and byte order are evaluated separately from application identity.

Which network path carries the case response? Evaluate byte, IP-route, socket and firewall evidence separately from the application returning the correct book.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

14-byte Ethernet header and neighbor summary

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "interface": {
    "name": "eth-demo",
    "ipv4": "192.0.2.10",
    "mac": "02:00:00:00:00:10"
  },
  "frameHeader": {
    "hex": "0200000000010200000000100800",
    "lengthBytes": 14,
    "fields": [
      {
        "name": "destinationMac",
        "offset": 0,
        "length": 6,
        "value": "02:00:00:00:00:01"
      },
      {
        "name": "sourceMac",
        "offset": 6,
        "length": 6,
        "value": "02:00:00:00:00:10"
      },
      {
        "name": "etherType",
        "offset": 12,
        "length": 2,
        "value": "0x0800"
      }
    ]
  },
  "payloadSummary": {
    "sourceIp": "192.0.2.10",
    "destinationIp": "198.51.100.200",
    "nextHopIp": "192.0.2.1",
    "kind": "IPv4 summary; bytes omitted"
  },
  "neighbors": [
    {
      "family": "IPv4",
      "ip": "192.0.2.1",
      "mac": "02:00:00:00:00:01",
      "resolution": "ARP",
      "teachingState": "known"
    },
    {
      "family": "IPv6",
      "ip": "2001:db8:1::1",
      "mac": "02:00:00:00:00:01",
      "resolution": "ICMPv6 Neighbor Discovery",
      "teachingState": "known"
    }
  ],
  "arpSummary": {
    "opcode": 1,
    "senderProtocolAddress": "192.0.2.10",
    "senderHardwareAddress": "02:00:00:00:00:10",
    "targetProtocolAddress": "192.0.2.1",
    "targetHardwareAddress": "unspecified in this summary"
  },
  "stream": {
    "writes": [
      "AB",
      "CDEF"
    ],
    "possibleReads": [
      "A",
      "BCD",
      "EF"
    ],
    "expectedConcatenation": "ABCDEF"
  }
}

hex / offset / length: Header bytes and zero-based field positions; no payload/FCS/padding.
destinationMac / nextHopIp: Local frame neighbor, potentially distinct from remote IP destination.
arpSummary.targetProtocolAddress: Local IPv4 next hop to resolve, not a raw ARP packet.
teachingState / resolution: Teaching outcome and IPv4/IPv6 distinction, not an OS state name.
writes / possibleReads: Illustrative TCP stream chunks without preserved message boundaries.

Synthetic header-only hex and summary JSON. It proves no complete Ethernet/ARP/ND packet, checksum/FCS, capture or delivery. Addresses are documentation/local examples.

Two reality checks

One TCP read returns a complete HTTP message.

TCP is a byte stream; application framing and buffering establish message boundaries.

The first Ethernet frame to a remote server uses that server’s MAC.

For a remote IPv4 target, the first frame typically uses the next-hop gateway MAC while IP destination identifies the remote target.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

Two TCP writes are AB and CDEF; reads are A, BCD, EF. Is the data corrupted?

No; the concatenated byte stream is ABCDEF.
Yes; each read must have the same length as one write.

Read the explained answer

No; the concatenated byte stream is ABCDEF. — A TCP stream does not preserve write boundaries; the selected reads reconstruct the same byte order.

Why does the frame destination MAC not identify the same actor as the Internet destination IP?

Selected lesson artifact fields; teaching example

frameHeader.fields[0].value: 02:00:00:00:00:01
payloadSummary.destinationIp: 198.51.100.200
payloadSummary.nextHopIp: 192.0.2.1

The MAC identifies the local next hop; the IP identifies the final destination.
The MAC field is the remote server’s global identity.

Read the explained answer

The MAC identifies the local next hop; the IP identifies the final destination. — The selected Ethernet frame goes to the gateway MAC; the IPv4 destination remains 198.51.100.200.

There is an ARP record for the IPv4 gateway and a Neighbor Discovery record for the IPv6 gateway. Why should they not be described as one protocol?

Read the explained answer

The IPv4 example uses ARP to resolve a local protocol-address/hardware-address relationship. The IPv6 example uses ICMPv6 Neighbor Discovery. Both may supply next-hop neighbor information; they are not the same wire format or protocol. An unobserved reply alone does not prove the neighbor never exists.

□ I kept ARP in IPv4 and ND in IPv6 context.

□ I did not treat an unobserved reply as proof of absence.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

RFC 9293 — TCP2.2 Key TCP Concepts · 3.1 Header Format · 3.2 Terminology · 3.3.2 State Machine Overview · 3.9.1 The User/TCP Interface · 3.7 Segmentation
RFC 768 — UDPFormat · Fields
RFC 894 — IP over EthernetFrame Format · Address Mappings · Byte Order
RFC 826 — ARPPacket format · Packet Generation · Packet Reception
RFC 4861 — IPv6 Neighbor Discovery3 Protocol Overview · 5.2 Conceptual Sending Algorithm · 7.2 Address Resolution · 11 Security Considerations
RFC 1122 — Internet Host Communication Layers2.3.2 ARP · 2.3.3 Ethernet and IEEE 802 Encapsulation · 3.3.1.1 Local/Remote Decision · 3.3.1.2 Gateway Selection
RFC 7042 — IANA/IEEE 802 Parameters2.1 EUI-48 Identifiers and MAC Addresses
RFC 5737 — Documentation IPv43 Documentation Address Blocks
RFC 3849 — Documentation IPv62 Documentation IPv6 Address Prefix

YOUR NOTES / THIS BROWSER

From bytes to the local network

1. Core · Mechanism

Known cache · IPv4

Unknown → ARP → known

No observed reply · no delivery

IPv6 · ND instead of ARP

A byte boundary is not a message boundary

Stream → segment → packet → frame

Interface and local delivery

Which IPv4 address does ARP resolve?

The scope of IPv6 Neighbor Discovery

2. Red · Trust & Impact

Write chunks

Read chunks

Misreading stream boundaries

Treating a local mapping as identity proof

A wrong interface changes the scope

3. Blue · Secure development & defense

Known next hop

Neighbor absent

Read a header at its own layer

Known, unknown and another protocol

Explainable consistency checks

Do stream chunks or a MAC establish application trust?

Two reality checks

Two TCP writes are AB and CDEF; reads are A, BCD, EF. Is the data corrupted?

Why does the frame destination MAC not identify the same actor as the Internet destination IP?

There is an ARP record for the IPv4 gateway and a Neighbor Discovery record for the IPv6 gateway. Why should they not be described as one protocol?

Sources and scope