Networking / Basic: packet paths and addressing / Lesson 1

Follow TCP/IP layers and endpoint identities

Build a packet-path model that separates local links, routed addresses, transport endpoints, and application identities.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain encapsulation and the responsibilities of each layer.
Distinguish MAC addresses, IP addresses, ports, and names.
Reason from a declared observation point without sending traffic.

Layers divide responsibilities

An application creates meaningful messages, a transport provides a communication service, IP moves packets across routed networks, and a link carries a frame to the next local recipient. These layers are a reasoning model rather than separate physical boxes. A host implements several of them, while a router commonly forwards based on IP information. Encapsulation places one layer’s data inside another layer’s payload. Removing a header at a receiver is not equivalent to decrypting the application. Keep the layer named in a question explicit so an Ethernet observation is not mistaken for proof of application success.

Each identity answers a different lookup question

A MAC address identifies a link-layer interface in a local forwarding context. An IP address identifies an interface or endpoint role within an addressing and routing design. A transport port helps distinguish services or conversations on an address, and a DNS name provides an application-facing naming indirection. None of these identities alone proves the intended user or server is authenticated. A proxy can terminate one connection and open another, changing endpoint identities between observations. Record the source, destination, protocol, ports, and observation point before comparing two descriptions of the same user request.

python Render a declared synthetic transport flow

flow = {'src': '192.0.2.10', 'sport': 51000, 'dst': '198.51.100.20', 'dport': 443, 'protocol': 'TCP'}
print(f"{flow['protocol']} {flow['src']}:{flow['sport']} -> {flow['dst']}:{flow['dport']}")

Expected output

TCP 192.0.2.10:51000 -> 198.51.100.20:443

The dictionary is teaching data using documentation addresses. Formatting it does not open a socket, resolve a name, or contact either address.

Local delivery and end-to-end intent differ

When a destination is off-link, a host normally sends the frame toward a selected next hop rather than learning the remote server’s MAC address. Across a routed hop, link headers can change while the IP packet continues toward its destination, subject to forwarding updates such as hop-limit reduction. NAT and tunnels can introduce additional transformations that must be named separately. A successful first-hop delivery establishes only part of the path. Conversely, a failure to reach the local next hop can prevent every higher-layer service even when DNS records and application credentials are correct.

Account for headers at the layer being measured

Payload bytes, IP packet length, and wire occupancy are different quantities. A simplified calculation can add known headers, but real traffic can include options, extension headers, framing, acknowledgements, and retransmissions. Do not subtract one universal number from every interface MTU to claim an application payload limit. State which protocol versions and headers the example assumes. Offload and aggregation can also change what a host-side observation displays. The example below is deliberately a declared arithmetic model, not a packet builder or a claim about an actual interface.

python Calculate a simplified IPv4/UDP packet length

payload = 100
ipv4_header = 20
udp_header = 8
print(f'synthetic_ip_packet={payload + ipv4_header + udp_header} bytes')

Expected output

synthetic_ip_packet=128 bytes

The model assumes no IPv4 options and counts only IP plus UDP plus application data. Ethernet framing and other traffic are intentionally outside this declared total.

Ask what an observation actually proves

A name response, TCP handshake, TLS authentication, and successful application response prove different milestones. Troubleshooting becomes clearer when each statement includes its layer, scope, and time. Avoid saying the network works because one unrelated request succeeded, or that a timeout proves a firewall dropped a packet. Preserve the exact error and compare a matching successful case. This course uses offline packet descriptions, calculations, and protocol-state fixtures only; it never scans, captures live traffic, changes interfaces, or administers a network device. The goal is accurate reasoning that can later guide an authorized operational investigation.

Common errors and fixes

A port number is treated as proof of application identity

Why it happens: Service convention was confused with authentication.
How to fix it: Verify the protocol and authenticated application endpoint.
Prevent it next time: Separate addressing from trust decisions.

A host searches for a remote server’s MAC

Why it happens: Off-link routing was mistaken for local neighbor resolution.
How to fix it: Identify the chosen next hop first.
Prevent it next time: Draw local and routed boundaries.

One successful layer is called complete connectivity

Why it happens: Later protocol milestones were not checked.
How to fix it: State exactly which milestone succeeded.
Prevent it next time: Keep a layered evidence checklist.

Check your understanding

1. A DNS answer exists but TLS authentication fails. Which success can be claimed?

Show worked solution

The observed name lookup succeeded for its scope and time. It does not prove the selected server identity or application authorization. Continue at the failed TLS milestone while preserving the resolved address and requested hostname.

2. For an off-link destination, whose link-layer address does the sender usually need?