WEB / WEB-02.04

A packet’s journey across the Internet

Follow one synthetic datagram through two routers: frames change per link, ordinary IP destination remains, and forwarding hops reduce TTL.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Ordinary IPv4 · no NAT

Selected datagram ready
DNS result and route/neighbor context are initial conditions; no handshake or HTTP success is shown.
Host
192.0.2.10:51000 → 198.51.100.200:443 · TTL 4
Router R1
No ingress yet
Router R2
No ingress yet
Endpoint
No IP packet yet
Host local egress preparation
Local route lookup and first-link header preparation are not transfers. IP destination remains the remote endpoint.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 4
Router R1
No ingress yet
Router R2
No ingress yet
Endpoint
No IP packet yet
R1 received the first-hop packet
Arrival updated R1 context. R2 and the endpoint have not received data.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 4
Router R1
Ingress 192.0.2.10:51000 → 198.51.100.200:443 · TTL 4
Router R2
No ingress yet
Endpoint
No IP packet yet
R1 local forwarding
R1 selects R2, reduces TTL 4→3 and replaces the egress MAC pair. Ordinary routing preserves IP source/destination.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 4
Router R1
Egress 192.0.2.10:51000 → 198.51.100.200:443 · TTL 3 · MAC …02:01 → …02:02
Router R2
No ingress yet
Endpoint
No IP packet yet
R2 received the packet
R1→R2 link delivery completed; endpoint arrival has not.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 4
Router R1
Egress 192.0.2.10:51000 → 198.51.100.200:443 · TTL 3 · MAC …02:01 → …02:02
Router R2
Ingress 192.0.2.10:51000 → 198.51.100.200:443 · TTL 3
Endpoint
No IP packet yet
R2 local forwarding
R2 selects egress and builds a new link frame with TTL 3→2. This local change sends no packet to another actor.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 4
Router R1
Egress 192.0.2.10:51000 → 198.51.100.200:443 · TTL 3 · MAC …02:01 → …02:02
Router R2
Egress 192.0.2.10:51000 → 198.51.100.200:443 · TTL 2 · MAC …03:02 → …03:20
Endpoint
No IP packet yet
Endpoint received the IP packet
The selected network journey completed; TCP/TLS/HTTP parsing and permissions are not added to this result.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 4
Router R1
Egress 192.0.2.10:51000 → 198.51.100.200:443 · TTL 3 · MAC …02:01 → …02:02
Router R2
Egress 192.0.2.10:51000 → 198.51.100.200:443 · TTL 2 · MAC …03:02 → …03:20
Endpoint
IP arrival 192.0.2.10:51000 → 198.51.100.200:443 · TTL 2 · no app outcome

R1 optional source PAT

Selected datagram ready
DNS result and route/neighbor context are initial conditions; no handshake or HTTP success is shown.
Host
192.0.2.10:51000 → 198.51.100.200:443 · TTL 4
Router R1
No ingress yet
Router R2
No ingress yet
Endpoint
No IP packet yet
Host local egress preparation
Local route lookup and first-link header preparation are not transfers. IP destination remains the remote endpoint.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 4
Router R1
No ingress yet
Router R2
No ingress yet
Endpoint
No IP packet yet
R1 received the first-hop packet
Arrival updated R1 context. R2 and the endpoint have not received data.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 4
Router R1
Ingress 192.0.2.10:51000 → 198.51.100.200:443 · TTL 4
Router R2
No ingress yet
Endpoint
No IP packet yet
R1 local forwarding + PAT
R1 selects R2, reduces TTL 4→3 and replaces the egress MAC pair. Optional PAT rewrites source address/port to the outside tuple.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 4
Router R1
Egress 203.0.113.5:45000 → 198.51.100.200:443 · TTL 3 · MAC …02:01 → …02:02
Router R2
No ingress yet
Endpoint
No IP packet yet
R2 received the packet
R1→R2 link delivery completed; endpoint arrival has not.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 4
Router R1
Egress 203.0.113.5:45000 → 198.51.100.200:443 · TTL 3 · MAC …02:01 → …02:02
Router R2
Ingress 203.0.113.5:45000 → 198.51.100.200:443 · TTL 3
Endpoint
No IP packet yet
R2 local forwarding
R2 selects egress and builds a new link frame with TTL 3→2. This local change sends no packet to another actor.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 4
Router R1
Egress 203.0.113.5:45000 → 198.51.100.200:443 · TTL 3 · MAC …02:01 → …02:02
Router R2
Egress 203.0.113.5:45000 → 198.51.100.200:443 · TTL 2 · MAC …03:02 → …03:20
Endpoint
No IP packet yet
Endpoint received the IP packet
The selected network journey completed; TCP/TLS/HTTP parsing and permissions are not added to this result.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 4
Router R1
Egress 203.0.113.5:45000 → 198.51.100.200:443 · TTL 3 · MAC …02:01 → …02:02
Router R2
Egress 203.0.113.5:45000 → 198.51.100.200:443 · TTL 2 · MAC …03:02 → …03:20
Endpoint
IP arrival 203.0.113.5:45000 → 198.51.100.200:443 · TTL 2 · no app outcome

TTL 1 · stops at R1

Selected datagram ready
DNS result and route/neighbor context are initial conditions; no handshake or HTTP success is shown.
Host
192.0.2.10:51000 → 198.51.100.200:443 · TTL 1
Router R1
No ingress yet
Router R2
No ingress yet
Endpoint
No IP packet yet
Host local egress preparation
Local route lookup and first-link header preparation are not transfers. IP destination remains the remote endpoint.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 1
Router R1
No ingress yet
Router R2
No ingress yet
Endpoint
No IP packet yet
R1 received the first-hop packet
Arrival updated R1 context. R2 and the endpoint have not received data.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 1
Router R1
Ingress 192.0.2.10:51000 → 198.51.100.200:443 · TTL 1
Router R2
No ingress yet
Endpoint
No IP packet yet
TTL blocks local forwarding
Forwarding decrement reached zero; no onward delivery. Standard ICMP behavior is separate; this scene generates no actual reply.
Host
Next hop R1 · src MAC …01:10 → dst …01:01 · TTL 1
Router R1
Forwarding TTL 1→0 · discard; ICMP omitted
Router R2
No ingress yet
Endpoint
No IP packet yet

ACTORS · STATE · DATA FLOW

The journey starts after an address result

The question here is how a selected IP datagram traverses next hops. Assume the application obtained an address for notes.example.org and selected 198.51.100.200. This initial condition shows neither DNS resolution nor established TCP/TLS. A warm connection or cache can avoid a new DNS exchange.

The example summarizes TCP endpoints as 192.0.2.10:51000 → 198.51.100.200:443. One datagram is not an entire HTTP message; the stream can use other segments. Headers are field summaries without invented checksums, sequence numbers or TLS bytes. Omitted state is not filled in as successful.

Each router makes its own local decision

The host route selects R1 and the Ethernet frame addresses its interface MAC. On arrival R1 distinguishes local IP delivery from forwarding toward another destination, then uses its own routing table to select R2 and an egress interface. The host’s default gateway does not specify the whole path.

The fixture selects just two forwarding routers. Actual Internet topology, convergence, tunnels, policy routing and ECMP are omitted. Arrival at one router does not establish downstream arrival. Route lookup and egress-header preparation are local processing, not separate network arrows.

A new frame is built for each link

The host→R1 MAC pair is not reused on the R1→R2 and R2→endpoint links. The router’s egress-interface MAC becomes the new frame source and the next neighbor’s MAC becomes its destination. We select Ethernet links without asserting all Internet links use Ethernet.

In the ordinary routed case the IP source remains 192.0.2.10 and destination 198.51.100.200. Saying the packet stays the same cannot mean every byte is identical: TTL and IPv4 header checksum change during forwarding. Link framing, IP forwarding and address translation are separate mechanisms.

TTL bounds a path; it is not DNS TTL

The selected IPv4 datagram leaves the host with TTL 4. R1 reduces it to 3 and R2 to 2 when forwarding. Each forwarding router decrements TTL by at least one; the fixture chooses one per router. Although historically a seconds-based field, normal rapid forwarding gives it a hop-limit effect.

In the TTL 1 branch the packet reaches R1, but forwarding decrement reaches zero and it is not sent onward. The standard defines ICMP Time Exceeded behavior; this scene does not fabricate receipt of an ICMP reply. DNS record TTL instead bounds cache lifetime. IPv6 uses Hop Limit rather than a copied IPv4 header.

NAT is explicit; destination arrival has limits

The normal path has no translation. Optional PAT rewrites the source at R1 to 203.0.113.5:45000 while preserving the remote destination. R2 and the endpoint see the outside tuple on this selected path. This is a chosen mapping, not live gateway state or a firewall verdict. A return needs its reverse mapping; it need not traverse an identical physical router sequence.

The modeled journey ends when the endpoint receives the IP packet. Matching transport endpoint, TCP state, TLS identity, HTTP parsing and application authorization remain separate conditions. The final card does not say HTTP 200; arrival establishes modeled IP delivery only.

Read every scenario without motion

First-hop boundary

Local success is not the whole path
HOST_R1 describes the first link’s MAC pair. A correct gateway MAC does not establish R2 routing, endpoint delivery or permission.
First-hop evidence
HOST_R1 / ttl=4
Forwarding boundary
r1 stage
Resource authority
No application grant
The router owns its forwarding boundary
Normal initial.ttl=4 becomes 3 at r1 egress. The link MAC pair changes while IP destination 198.51.100.200 remains.
First-hop evidence
HOST_R1 / ttl=4
Forwarding boundary
R1_R2 / ttl=3
Resource authority
No application grant
Header changes belong to scope
Egress MAC changes and forwarding TTL decrement are ordinary. If optionalPat is selected, r1 also changes the source tuple; these differences alone do not prove malicious activity.
First-hop evidence
MAC/link + TTL/hop scope
Forwarding boundary
R1_R2 / ttl=3
Resource authority
No application grant
No downstream outcome was invented
R2_END shows ttl=2. Supplied summaries for three links do not claim a TCP handshake or endpoint application acceptance.
First-hop evidence
MAC/link + TTL/hop scope
Forwarding boundary
R2_END / ttl=2
Resource authority
No application grant
Resource rights do not come from the network
initial.destinationPort=443 and IP arrival establish neither application identity nor resource ownership. Endpoint verified-subject and object-policy checks must remain separate.
First-hop evidence
MAC/link + TTL/hop scope
Forwarding boundary
R2_END / ttl=2
Resource authority
Network reach ≠ resource grant
The failure boundary was named correctly
The supplied normal path is consistent in its network scope. applicationOutcome=not-modeled prevents adding a successful book read or permission outcome.
First-hop evidence
MAC/link + TTL/hop scope
Forwarding boundary
R2_END / ttl=2
Resource authority
Path fixture / app unknown

TTL boundary

Local success is not the whole path
HOST_R1 describes the first link’s MAC pair. A correct gateway MAC does not establish R2 routing, endpoint delivery or permission.
First-hop evidence
HOST_R1 / ttl=1
Forwarding boundary
r1 stage
Resource authority
No application grant
The router owns its forwarding boundary
expired.initialTtl=1 is received at r1 with forwardedBeyondR1=false. No downstream knowledge or ICMP generation is added.
First-hop evidence
HOST_R1 / ttl=1
Forwarding boundary
No forward beyond r1
Resource authority
No application grant
Header changes belong to scope
R1 discards the datagram when forwarding reduces TTL from 1 to 0. This branch produces no R1→R2 egress frame or PAT-transmitted outside tuple. Do not import the normal branch’s MAC/TTL changes as operations completed on this stopped path.
First-hop evidence
TTL 1→0 / no R1 egress
Forwarding boundary
No forward beyond r1
Resource authority
No application grant
No downstream outcome was invented
This branch does not update r2 or endpoint receipt. TTL failure belongs to r1’s boundary, not an application server’s authorization denial.
First-hop evidence
TTL 1→0 / no R1 egress
Forwarding boundary
Endpoint outcome not supplied
Resource authority
No application grant
Resource rights do not come from the network
This datagram does not reach the endpoint, so it is not shown triggering an application resource decision. TTL discard is not server authorization denial. Even a different datagram arriving at IP would still require verified-subject and object-policy checks.
First-hop evidence
TTL 1→0 / no R1 egress
Forwarding boundary
Endpoint outcome not supplied
Resource authority
Network reach ≠ resource grant
The failure boundary was named correctly
The known failure is the TTL boundary; ICMP generatedInModel=false and applicationOutcome=not-modeled remain intact. An actual timeout cannot automatically be assigned that cause.
First-hop evidence
TTL 1→0 / no R1 egress
Forwarding boundary
Endpoint outcome not supplied
Resource authority
TTL at r1 / app unknown

ASSUMPTION · BOUNDARY · CONTROL

Broken assumption: the first hop proves the whole path

A frame sent to the expected gateway MAC supports local delivery conditions, not complete evidence of R1 egress, R2 state or endpoint outcome. Set a security conclusion within the observer’s visible fields.

Promoting a local success to end-to-end permission can conceal a missing control. We describe a broken expectation in the toy path without route changes or traffic-manipulation workflows.

Broken assumption: every header field is stable

MAC pairs belong to links, translated tuples to observation points, and TTL to forwarding stages. Conflating these scopes can misclassify two observations of one flow. Preserved ordinary addressing is a property of the selected no-NAT branch.

Name the reason for a field change: new egress frames and TTL decrement are normal, while PAT source changes follow a selected mapping. A change alone proves neither malicious activity nor a successful exploit.

Broken assumption: reachability grants application rights

IP arrival may be a necessary network condition; it does not decide resource ownership or authorization. Port 443 and a destination address do not replace service identity. Application policy still needs enforcement.

Labeling TTL expiry, filtering and no-route as server rejection loses the failure boundary. This lesson models TTL expiry; other causes need their own evidence.

Read every scenario without motion

Hop scope

The first-link scope was labeled
HOST_R1 records source MAC 02:00:00:00:01:10 and destination MAC 02:00:00:00:01:01 on the first link. TTL there is 4. The observation does not show frames on other hops.
Link evidence
HOST_R1 / ttl=4
Scope correlation
No observer scope
Outcome review
No outcome
The next observer sees another frame
R1_R2 shows MAC pair …02:01 → …02:02 and ttl=3. Another MAC on another link is expected for the same flow, not proof of another account or event.
Link evidence
HOST_R1 / ttl=4
Scope correlation
R1_R2 / ttl=3
Outcome review
No outcome
Translation scope remained explicit
The normal branch has no NAT and retains the IP tuple. Importing that equality into a translated observation would be incorrect correlation.
Link evidence
HOST_R1 / ttl=4
Scope correlation
No-NAT IP tuple retained
Outcome review
No outcome
The final link has its own TTL
R2_END supplies ttl=2 and MAC pair …03:02 → …03:20. TTL arithmetic 4→3→2 belongs to the supplied forwarding model, not an executed packet capture.
Link evidence
R2_END / ttl=2
Scope correlation
No-NAT IP tuple retained
Outcome review
No outcome
A missing endpoint log does not establish cause
The expired branch supplies known initialTtl=1 and no-forward conditions. Missing actual endpoint telemetry does not establish those conditions; no event and no collection are separated.
Link evidence
R2_END / ttl=2
Scope correlation
No-NAT IP tuple retained
Outcome review
Absence ≠ TTL diagnosis
Hop correlation scope was preserved
Three supplied links show link-specific MAC and forwarding TTL changes for one tuple. Model consistency does not establish actual topology or service health.
Link evidence
R2_END / ttl=2
Scope correlation
No-NAT IP tuple retained
Outcome review
Hop/tuple scope agrees; application unknown

PAT scope

The first-link scope was labeled
HOST_R1 records source MAC 02:00:00:00:01:10 and destination MAC 02:00:00:00:01:01 on the first link. TTL there is 4. The observation does not show frames on other hops.
Link evidence
HOST_R1 / ttl=4
Scope correlation
No observer scope
Outcome review
No outcome
The next observer sees another frame
R1_R2 shows MAC pair …02:01 → …02:02 and ttl=3. Another MAC on another link is expected for the same flow, not proof of another account or event.
Link evidence
HOST_R1 / ttl=4
Scope correlation
R1_R2 / ttl=3
Outcome review
No outcome
Translation scope remained explicit
optionalPat at=r1 supplies source 192.0.2.10:51000 → 203.0.113.5:45000. Downstream source is not expected to equal the inside tuple.
Link evidence
HOST_R1 / ttl=4
Scope correlation
pre/post PAT separate
Outcome review
No outcome
The final link has its own TTL
R2_END supplies ttl=2 and MAC pair …03:02 → …03:20. TTL arithmetic 4→3→2 belongs to the supplied forwarding model, not an executed packet capture.
Link evidence
R2_END / ttl=2
Scope correlation
pre/post PAT separate
Outcome review
No outcome
A missing endpoint log does not establish cause
The expired branch supplies known initialTtl=1 and no-forward conditions. Missing actual endpoint telemetry does not establish those conditions; no event and no collection are separated.
Link evidence
R2_END / ttl=2
Scope correlation
pre/post PAT separate
Outcome review
Absence ≠ TTL diagnosis
Hop correlation scope was preserved
MAC/link, TTL/hop and PAT/observer differences are explained. Source-tuple translation supports a flow relationship, not account identity or application success.
Link evidence
R2_END / ttl=2
Scope correlation
pre/post PAT separate
Outcome review
Hop/tuple scope agrees; application unknown

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Read a hop ledger with its observer scope

The artifact records each link’s source/destination MAC pair and IP TTL. Explicit ingress/egress summary scope makes TTL comparisons meaningful. The values are selected fixture data rather than a capture.

Real correlation needs time/interface, pre/post NAT tuple and observation point. Do not expect a host-capture MAC pair in a remote server log; observers see different layers. Mark inferred outcomes separately from measurements.

Compare ordinary, translated and expired branches

On the ordinary path three link summaries retain the IP tuple while TTL changes 4→3→2. With PAT the first link uses inside source and later links outside source. With TTL 1, downstream receivers stay waiting and no forwarding arrow exists.

These differences are the lesson’s expected baselines. Missing endpoint arrival alone does not identify TTL as the cause; the fixture supplies that condition. In real analysis separate missing telemetry from missing delivery.

Review through hop and layer conditions

Review a route change through next hop and egress scope, a NAT change through mapping and return path, and an application change through endpoint permissions. One connectivity observation does not complete all three.

The hop-ledger fields describe the selected forwarding path: a MAC pair per link, TTL decrement per router, and PAT source translation when applied. Their consistency establishes no actual topology, ICMP delivery, TCP handshake or application outcome. For a running system, record the interface and time producing each observation; do not derive an unobserved higher-layer outcome from a lower-layer success.

NOW APPLY IT TO THE CASE

Which end-to-end conclusions do not follow from first-hop success?

A packet crosses three Ethernet links through two IPv4 routers. Each link changes the MAC pair; the normal path has TTL values 4, 3 and 2. A packet starting at TTL 1 stops at r1, without establishing an application outcome.

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

Hop ledger for three links

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

Read the raw artifact and field explanations

{
  "scope": "Three Ethernet links, two IPv4 forwarding routers; route and neighbor selection supplied; not a capture.",
  "initial": {
    "sourceIp": "192.0.2.10",
    "sourcePort": 51000,
    "destinationIp": "198.51.100.200",
    "destinationPort": 443,
    "transport": "TCP",
    "ttl": 4
  },
  "links": [
    {
      "id": "HOST_R1",
      "from": "host",
      "to": "r1",
      "sourceMac": "02:00:00:00:01:10",
      "destinationMac": "02:00:00:00:01:01",
      "sourceIp": "192.0.2.10",
      "destinationIp": "198.51.100.200",
      "ttl": 4
    },
    {
      "id": "R1_R2",
      "from": "r1",
      "to": "r2",
      "sourceMac": "02:00:00:00:02:01",
      "destinationMac": "02:00:00:00:02:02",
      "sourceIp": "192.0.2.10",
      "destinationIp": "198.51.100.200",
      "ttl": 3
    },
    {
      "id": "R2_END",
      "from": "r2",
      "to": "endpoint",
      "sourceMac": "02:00:00:00:03:02",
      "destinationMac": "02:00:00:00:03:20",
      "sourceIp": "192.0.2.10",
      "destinationIp": "198.51.100.200",
      "ttl": 2
    }
  ],
  "optionalPat": {
    "at": "r1",
    "before": {
      "sourceIp": "192.0.2.10",
      "sourcePort": 51000
    },
    "after": {
      "sourceIp": "203.0.113.5",
      "sourcePort": 45000
    },
    "destinationPreserved": true
  },
  "expired": {
    "initialTtl": 1,
    "receivedAt": "r1",
    "forwardedBeyondR1": false,
    "icmpGeneratedInModel": false
  },
  "applicationOutcome": "not-modeled"
}

links.sourceMac / destinationMac: A new Ethernet address pair per link, not end-to-end identity.
links.ttl: Selected TTL sent over that link, not DNS cache TTL.
optionalPat: Source address/port mapping applied only at R1.
applicationOutcome: Application outcome after IP arrival is explicitly omitted.

Inert header summary with two forwarding routers and selected Ethernet links. No capture, checksum/FCS, DNS exchange, ICMP reply, return topology or TCP/TLS/HTTP state.

Two reality checks

An Ethernet frame carries the same MAC pair across the Internet.

Each Ethernet link uses a new frame for its local next hop; ordinary IP destination is a separate layer.

IP arrival at the endpoint proves HTTP success.

IP delivery is distinct from TCP/TLS/HTTP and authorization. This fixture produces no application outcome.

YOUR TURN

Work through this story.

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

Does a packet reaching r1 with TTL=1 reach r2 in the selected expired branch?

No; it is not forwarded beyond r1.
Yes; r1 increases TTL and continues.

Read the explained answer

No; it is not forwarded beyond r1. — The expired record says forwardedBeyondR1=false; the model also does not claim to generate ICMP.

What changes and what is preserved between the first and last link records?

Selected lesson artifact fields; teaching example

links[0]: {"id":"HOST_R1","from":"host","to":"r1","sourceMac":"02:00:00:00:01:10","destinationMac":"02:00:00:00:01:01","sourceIp":"192.0.2.10","destinationIp":"198.51.100.200","ttl":4}
links[2]: {"id":"R2_END","from":"r2","to":"endpoint","sourceMac":"02:00:00:00:03:02","destinationMac":"02:00:00:00:03:20","sourceIp":"192.0.2.10","destinationIp":"198.51.100.200","ttl":2}

MAC headers and TTL change; IP source/destination are preserved.
Each router replaces the destination IP with its own IP.

Read the explained answer

MAC headers and TTL change; IP source/destination are preserved. — Each Ethernet link has different addressing; two routers reduce TTL from 4 to 2.

The packet reached the endpoint. Why can we not infer a successful TCP handshake and book response?

Read the explained answer

This artifact models forwarding and packet arrival. Bidirectional TCP handshake state, TLS and application responses are separate layers. With applicationOutcome not-modeled, endpoint arrival is not evidence of HTTP success or a DOM outcome.

□ I did not turn packet arrival into application success.

□ I identified the missing TCP/TLS/HTTP evidence.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

RFC 1812 — IPv4 routers5.2.1.2 Unicast forwarding · 5.2.3 Local Delivery Decision · 5.2.4 Next Hop Address · 5.3.1 Time to Live
RFC 894 — IP over EthernetFrame Format · Address Mappings
RFC 3022 — Traditional NAT2.1 Basic NAT · 2.2 NAPT · 3.1 Address binding · 3.2 Address lookup and translation
RFC 9293 — TCP2.2 Key TCP Concepts · 3.1 Header Format · 3.3.2 State Machine Overview
RFC 8200 — IPv63 IPv6 Header Format
RFC 1034 — DNS concepts2.2 DNS design goals · 3.1 Namespace specifications and terminology · 3.6.2 Aliases and canonical names · 4.2 How the database is divided into zones · 4.3.1 Queries and responses · 4.3.2 Algorithm · 5.3.1 Stub resolvers
RFC 5737 — Documentation IPv43 Documentation Address Blocks
RFC 2606 — Reserved example domains3 Reserved Example Second Level Domain Names

YOUR NOTES / THIS BROWSER

A packet’s journey across the Internet

1. Core · Mechanism

Ordinary IPv4 · no NAT

R1 optional source PAT

TTL 1 · stops at R1

The journey starts after an address result

Each router makes its own local decision

A new frame is built for each link

TTL bounds a path; it is not DNS TTL

NAT is explicit; destination arrival has limits

2. Red · Trust & Impact

First-hop boundary

TTL boundary

Broken assumption: the first hop proves the whole path

Broken assumption: every header field is stable

Broken assumption: reachability grants application rights

3. Blue · Secure development & defense

Hop scope

PAT scope

Read a hop ledger with its observer scope

Compare ordinary, translated and expired branches

Review through hop and layer conditions

Which end-to-end conclusions do not follow from first-hop success?

Two reality checks

Does a packet reaching r1 with TTL=1 reach r2 in the selected expired branch?

What changes and what is preserved between the first and last link records?

The packet reached the endpoint. Why can we not infer a successful TCP handshake and book response?

Sources and scope