Summary

  • RFC 4084 separates Web-only, client-only, firewalled and full connectivity without declaring one morally superior; its concern is what a provider supplies or permits and what the customer is told.
  • A credible access offer needs a versioned capability receipt that keeps the advertisement, contract, provider configuration and controlled observations separate. A tunnel or relay that happens to work is not the same thing as a supported operating right.

The purchase order has one noun and many missing verbs

An enterprise signs for “Internet access”. The first week looks successful: browsers load, video calls connect and a speed test reaches the purchased rate. Then the real workload arrives. A branch VPN fails after idle periods. A monitoring collector cannot accept an inbound session. A developer’s peer-to-peer test works from one mobile network but not another. Outbound mail must use the provider’s relay. The public address visible to a website is not the address assigned to the customer equipment.

None of those outcomes contradicts the original label. The problem is that the label never stated the verbs the customer needed the connection to perform.

RFC 4084 was published in 2005 to reduce exactly this ambiguity. It observes that products advertised as “Internet” or “Internet access” can differ substantially. It then offers neutral names for a ladder of arrangements: Web connectivity; client-only access without a public address; client-only access with a public address; firewalled Internet connectivity; and full Internet connectivity. The document is careful about its politics. Listing a model does not endorse it, and a narrower service is not fraudulent merely because it is narrower. The obligation is disclosure.

That restraint is why the document remains useful. Procurement does not need a philosophical verdict on whether a connection is “real Internet”. It needs a record of what the connection lets the customer operate.

An address is not an operating permission

RFC 4084 refuses to collapse addressing and capability. A non-public address usually places servers and many peer-to-peer functions behind translation. A public address may make most VPNs feasible while the provider still prohibits servers in the contract or filters inbound attempts. A static public address is stronger evidence, but it does not answer every question about ports, proxies, DNS, mail or interception.

The practical inventory therefore begins with more than “IPv4 included”. It asks whether the customer receives public IPv4, IPv6, both or neither; whether the assignment is exclusive or shared; whether it changes; how third parties classify it; whether reverse DNS is available; and whether unsolicited inbound traffic can reach the customer. It records the point at which translation occurs and who controls it.

RFC 4787 sharpens the NAT part of that inventory. Mapping behavior and filtering behavior are separate. A mapping can be endpoint-independent while inbound packets are still admitted according to a different rule. Timers can expire, outbound packets can refresh state, and stricter filtering can force applications to use relays. “The application connected once” is therefore an observation about one path and one period of state, not a durable description of the service.

This matters for the distinction RFC 4084 makes between provider intent and a workaround. A rendezvous service, relay or tunnel may restore an application’s reachability. That is useful engineering. It does not prove that inbound operation is supported, that the contract permits a server, or that the provider will preserve the behavior after a network change.

The receipt needs four columns

A capability receipt is not a new badge. It is a joined record with four columns that must not overwrite one another.

Advertised records the product name, the provider’s chosen connectivity description, the publication date and the sales statement. It tells the buyer what was represented before purchase.

Contracted records permissions and prohibitions: server operation, peer-to-peer use, address stability, customer-selected firewalling, provider filtering, mail relay requirements, acceptable-use boundaries and support obligations. It tells the buyer which successful experiments the provider is actually obliged to keep working.

Configured records the provider-controlled technical surface: address sharing, NAT, inbound and outbound filters, proxying, DNS requirements, ICMP treatment, VPN or tunnel restrictions, mail diversion and customer-requested security controls. This column needs a change identity, not merely a timeless “enabled”.

Observed records a controlled test: date, customer and external vantage, address seen at each edge, protocol and port, traffic direction, repetitions, timeouts, results and uncertainty. It can say that an inbound TCP session reached a host from two independent networks, or that a UDP rendezvous required a relay. It cannot silently rewrite the contract or infer provider intent.

The receipt also needs explicit fields for responsible party, customer-requested restriction, workaround dependency, known exceptions and retest trigger. Those fields prevent a common category error: treating a customer’s managed firewall choice as an ISP limitation, or treating an ISP restriction as an accidental property of the customer’s router.

Mail exposes the cost of vague connectivity

Mail is the clearest example because several layers can fail independently. RFC 4084 discusses providers that require their own submission server, block access to other messaging ports, divert outbound traffic, restrict remote mailbox access or classify dynamic addresses in ways that affect delivery. It says these conditions should be disclosed and gives stronger disclosure language for particular outbound filtering and diversion.

A useful receipt does not reduce this to “email supported”. It separately records authenticated submission, arbitrary external SMTP reachability, POP3/IMAP4 access, permitted sender domains, reverse DNS, address reputation treatment and any redirection to provider infrastructure. A Web mailbox working in a browser does not establish those properties. Nor does one successful message prove that a self-operated mail service is supportable from the connection.

The same discipline applies to VPNs. “VPN compatible” should identify the tested tunnel families, direction, idle behavior, address changes and whether success depended on an application-layer fallback. It applies to DNS: may the customer reach arbitrary resolvers, or is traffic redirected? It applies to ICMP: which diagnostic messages cross the boundary? It applies to inbound HTTP, HTTPS, FTP and unrecognised applications: which are prohibited, filtered or simply untested?

A restriction has an owner

RFC 7754 adds a second discipline. The party that sets a blocking policy and the party that enforces it may not be the same. A failed connection cannot identify motive, authority or intent by itself. The receipt should therefore name the actor that requested the restriction, the actor that implemented it and the technical surface where it appeared.

That attribution protects providers as much as customers. It prevents an enterprise firewall, endpoint policy or customer-selected managed-security option from being blamed on the access network. It also prevents a provider-imposed restriction from disappearing into the word “security”. A bounded statement—“inbound TCP 25 was filtered at the provider edge during these tests, under this contract clause”—is more defensible than a broad accusation and more useful than silence.

Sources