Internet architecture

The Internet architecture comprises its protocol interfaces, addressing and naming arrangements, placement of functions and assumptions about communication. Physical connectivity, administrative control and application trust are distinct dimensions of this architecture.^[ref]

Internet service federation permits independently administered services to communicate through agreed protocols. Internet mail is an example: separate domains can exchange messages without every user joining one provider. Federation differs from placing many replicas behind one mandatory account authority, and it does not itself establish cryptographic confidentiality or freedom from software failures.^[ref]

A middlebox performs a function on a communication path beyond ordinary Internet Protocol forwarding, such as address translation, traffic filtering or proxying. The function can be embedded in a device rather than implemented in a separate physical box. Its state and assumptions can affect failure recovery and protocol evolution.^[ref]

A proxy server performs communication operations on behalf of another participant. Whether it can inspect plaintext depends on the protocols and keys it uses: relaying opaque encrypted bytes differs from authorised TLS termination.

A firewall enforces a communication policy, for example by filtering packets or tracking permitted exchanges. Blocking unwanted incoming traffic is a policy decision; it is not the definition of network address translation.

Network address translation maps IP addresses between address realms. State and path constraints can affect sessions. Network address and port translation additionally maps transport ports. Translation does not itself require decryption of application payloads.^[ref]

Network address and port translation permits several internal addresses and transport ports to share an external address by maintaining distinct translated bindings. Losing a binding can disrupt an exchange even when the application endpoints retain their own state.

Fate-sharing places state needed by a communicating endpoint with that endpoint, so that failure of an unrelated forwarding component need not erase the state of an ongoing exchange. This can help communication recover after a route change when a path becomes available again. It does not mean every router lacks state or that communication can survive loss of all paths.^[ref]

The IP hourglass describes a common narrow inter-network layer supporting many applications above it and many network technologies below it. Keeping that interface general limits the need for every application developer and link provider to coordinate separate application-specific changes.^[ref]

Network decentralisation concerns the distribution of relevant control, authority or indispensable dependencies across independently operated participants. It is a property relative to a specified decision or service: distributed forwarding can coexist with centralised naming, credentials or application data. Counting physical servers is insufficient.

Construct a service with replicas in ten locations, all controlled by the same operator and all requiring that operator's account authority. The physical deployment is distributed, but control and the account dependency remain centralised. Increasing the number of sites leaves that counterexample intact. To assess decentralisation, state which operators can independently authorise participation, change protocol behaviour or preserve service when another operator fails.

When fully implementing a required function needs endpoint information, a lower-layer implementation cannot replace endpoint responsibility. Lower-layer mechanisms can still improve efficiency. The principle concerns function placement, not a requirement for peer-to-peer topology. Jerome H. Saltzer, David P. Reed and David D. Clark articulated the argument.^[ref]

Suppose an application's required property depends on endpoint state that is not determined by the network trace. Consider two executions with identical messages and forwarding behaviour: in one the receiver stores the received byte correctly; in the other it corrupts that byte after reception. The network trace is the same, but the required stored-file correctness differs. Any decision based only on that trace must give the same answer in both executions and therefore cannot establish the property for all executions.

This is an indistinguishability argument for that failure model, not a claim that network checks are useless. A link checksum may reduce transmission errors while an application endpoint still has to check the property that spans its storage and processing. Specify the endpoint boundary before claiming an end-to-end guarantee.