Summary

  • RFC 1681 proposed encoding a payer class, or an index to a charging algorithm, in a destination address so clients and border routers could act before contact.
  • The memo rejected learning the cost afterward and warned that connection-time notices could fail when software had no interaction hook or silently followed a Gopher redirect.
  • An address signal could select policy, but it could not by itself prove the human principal, current terms, informed approval, useful service, accurate metering, a valid invoice or payment.

A redirect could cross the commercial boundary first

The most revealing passage in RFC 1681 is not its address arithmetic. It is a short security scenario. Suppose, the memo asks, that a Gopher server redirects a caller to a pay-to-play address without showing the required warning. Many network interactions offered no place to pause for a human decision. A message displayed at connection time was therefore not enough.

The example was hypothetical. It did not document a Gopher fraud or prove that paid IP destinations existed. Its force came from ordering. Software could select a new destination and initiate contact before the person responsible for the cost had a reliable opportunity to understand or refuse it. Once the charge was discovered afterward, disclosure had failed even if every packet and accounting counter was technically correct.

Steven Bellovin's proposal was to move one piece of commercial meaning earlier. Encode the charging algorithm in the destination address, perhaps also in DNS. Some bits would determine who paid. A larger field could make the address an index into a charge-algorithm table. An organisational border router could then recognize paid-service classes and apply local rules before forwarding the traffic.

The address was not the bill. It was the warning label and policy selector placed where ordinary network machinery could see it soon enough to matter.

One host no longer meant one address

The billing idea sat inside a wider argument. Most end hosts in 1994 were treated as single-homed, and address-space forecasts often counted hosts. RFC 1681 argued that this could be a serious planning error because one machine might legitimately need many addresses.

A second address could identify a service rather than the physical host that happened to run it. Keeping that service address stable could make it easier to move the service to another machine. Different addresses on one host could expose different views or access policies without teaching users a new protocol or custom port. A firewall could admit one service address while excluding the host's other addresses, provided the server processes were correctly bound.

The memo considered putting port information into DNS instead. Its objection was migration cost: every relevant client would need to understand the new answer. Addressing was being asked to absorb service distinction because deployed applications already knew how to connect to an address.

That convenience also created semantic pressure. The same field could mean host locator, service identity, access-policy class, user session, mobility handle and charging category. Those meanings had different owners and lifetimes. A stable service address might outlive a machine. A user-session address might last only until logout. A charge-table entry could change while the destination bits did not. The packet format alone could not preserve all those clocks.

Four ways to answer “who pays?”

RFC 1681 listed four possible usage-sensitive charging arrangements. In ordinary pay-as-you-go, each host paid for its own packets, so both parties to a conversation could incur cost. Under caller-pays, the initiator carried the charge. A collect-call model shifted it to the recipient. A premium-service model resembled an American “900” number, where the caller paid more to reach the server.

The memo's hard requirement followed: caller and recipient had to know in advance who would pay. Finding out only after a cost had been incurred was unacceptable.

“Who pays” was still only one coordinate. The earlier RFC 1125 had decomposed charging policy into an accounting unit, measurement basis, actual amount, payer or payee, controlling packet count and bounds. That taxonomy shows why even a perfectly recognized payer bit could not finish the commercial decision. Which table version applied? Was the amount per byte, packet, interval or transaction? Whose counter controlled? Was there a spending ceiling? Which party could contest the record?

RFC 1681 did not pretend that one bit answered all of that. Its table-index extension made the dependency visible. If an address points to row 37, the meaning lives in row 37 as it existed under one operator at one time. Preserve only the address and the future investigator may retain the index while losing the rule it indexed.

The border could refuse without consenting for the user

The proposed organisational border router gave local policy an early enforcement point. RFC 1681 imagined that anonymous workstations in a dormitory laboratory might be barred from placing collect calls. The router could compare a destination class with the source's permitted class and decline the packet before a chargeable interaction developed.

That is meaningful running state: one device, under one administration, made one admission decision. It is not human consent. A permitted source address might be shared. A machine could act automatically. An account holder could have delegated only limited spending authority. The remote service might apply different terms from the table the border used. A routing decision could be correct while the eventual bill was wrong.

The memo also proposed a separate address for each logged-in user. Routers, which did not know who sat behind a host, could continue collecting traffic records against that address; the host would record the session assignment; billing could be performed offline. Different classes of users might receive address forms that allowed or denied costly services.

This design improved joinability, not identity magic. A reliable reconstruction would need both the router's measurements and the host's time-bounded assignment log. It would still need authentication, authorization, service records and the applicable charging table. A user-labelled address could narrow the candidate principal without proving who controlled the session or approved a particular cost.

A published white paper was not running charging code

The RFC Editor record classifies RFC 1681 as Informational. The memo says it was submitted to the IPng area in response to RFC 1550, and that publication did not imply acceptance of its ideas. RFC 1550 had solicited requirements and selection factors, including accounting, and described the resulting papers as resource material and part of the historical record.

The distinction prevents a seductive retrospective story. Multiple addresses did become ordinary in IPv6: RFC 4291 assigns addresses to interfaces and permits one interface to hold multiple addresses of different types and scopes. That fact does not show that IPv6 adopted RFC 1681's charging bits or that the 1994 proposal caused the later addressing model.

Service location also gained an explicit DNS record. RFC 2782 defines SRV fields for service, protocol, priority, weight, port and target, with protocol-specific applicability and security rules. SRV helps a client find a service. It does not standardize a price, payer, consent record, usage meter or invoice. Similar design pressures produced other mechanisms; they are not receipts for this proposal's deployment.

RFC 1681 recommended headroom for 2^6, perhaps 2^8, extra addresses per host. That was a planning allowance for possible service, user, mobility and allocation uses, not a measurement of consumption or a per-host entitlement. Its historical contribution is the warning that address demand follows meanings and lifetimes, not just boxes.

Preserve the chain from signal to settlement

An operational record for such a design would need at least ten distinct receipts: the destination chosen; the charge class or table index; the current table and its owner; the border decision; the authenticated user or account; the terms displayed before commitment; the remote service's acceptance and useful delivery; the measured unit and counter; the invoice calculation and contractual bounds; and payment, reversal or dispute outcome.

No earlier receipt silently proves the next. A recognized address class does not prove the table was current. Router admission does not prove the person consented. A successful connection does not prove useful service. A packet count does not prove the correct unit price. An invoice does not prove settlement.

Heng Lu's Running-Code Primacy supplies the first discipline: proposal, publication and address label must not be promoted into adopted or observed reality. Minimum Initial Specification supplies the second: shared interoperability fields should be separated from business arrangements and policy decisions that can remain local. Reality, Not Advocacy supplies the editorial limit: the point is neither to revive charging bits nor to mock them, but to preserve what the record shows and what it cannot.

RFC 1681 asked the address to warn the network before the network spent somebody's money. The durable lesson is narrower than the mechanism. Early machine-readable terms can reduce surprise only when identity, authorization, delivery, measurement and settlement remain independently provable.

Sources