Summary

  • RFC 1877 let a PPP endpoint request primary and secondary DNS and NBNS addresses through four IPCP options; zero was an explicit request for the peer to propose the information in Configure-Nak.
  • The Nak was advice, not acceptance. The requester still had to send a revised Configure-Request, receive a matching Configure-Ack and reach IPCP Opened before IP traffic belonged on the link.
  • A negotiated address proved neither reachability nor name resolution. Query delivery, response correlation, answer authority, local policy and application use each required separate evidence.

Zero could be the most precise request

By December 1995, the dial-up path to the Internet had acquired a small configuration problem with a large practical effect. A host could obtain an IP connection over the Point-to-Point Protocol and still lack the address of the service that turned names into addresses. Typing a numeric destination might work while an ordinary hostname did not. The link was present; the application experience was not.

RFC 1877 addressed that gap by extending the Internet Protocol Control Protocol, or IPCP. It defined four six-octet options. Type 129 carried a primary DNS server address, 130 a primary NetBIOS Name Server address, 131 a secondary DNS server address and 132 a secondary NBNS address. Each consisted of the type, a length of six and one four-octet IPv4 address.

The source text itself needs an evidentiary caveat. In section 1.3, one stray field-description phrase names a primary NBNS server, while the section title, packet diagram and type 131 assignment all identify secondary DNS. That conflict is a documentary limit; the isolated phrase cannot be promoted into protocol semantics over the mutually reinforcing title, diagram and assigned number.

The client could ask for an address by sending the option with all four address octets set to zero. That was not a damaged field or a claim that a resolver lived at 0.0.0.0. The zero value explicitly asked the remote peer to provide information in a Configure-Nak. More generally, RFC 1877 expected the local peer to offer an address it knew would be invalid so the other end would answer with one it considered valid.

This was an elegant use of rejection. The negative response carried useful direction without pretending that the original request had succeeded. It also left an evidentiary trail whose steps mattered.

A Nak proposed; it did not configure

RFC 1877 deliberately copied the format and behaviour of IPCP's existing IP-Address option. RFC 1332 had already placed Configure-Request, Configure-Ack, Configure-Nak and Configure-Reject inside the NCP for IP. A Nak could report an acceptable value, but it could not edit the packet awaiting a decision.

Suppose the local endpoint requested primary DNS address 0.0.0.0. The remote peer returned a Nak containing 192.0.2.53. At that moment the trace established three things: the request arrived, the remote implementation understood the option, and it proposed that address. The local side still had to decide whether to issue another Configure-Request containing 192.0.2.53. Only an Ack that matched the latest request established acceptance of that proposal as the negotiated value.

The distinction is more than packet-lawyer neatness. If a monitor records the Nak as “DNS configured,” it erases the local endpoint's next decision. If it records an Ack without the request that the Ack answers, it loses the object of consent. Reordered, duplicated or stale control packets can then look like present agreement when they are merely surviving evidence from another attempt.

The earlier PPP architecture in RFC 1661 gives the exchange its place. Physical readiness precedes Link Control Protocol establishment. Any required authentication follows. Only then does PPP reach its Network-Layer Protocol phase, where each network protocol is separately configured by its NCP. IPCP packets sent too early do not establish a usable IP configuration, and supported IP traffic belongs on the link only after IPCP reaches Opened.

An accepted DNS option is therefore nested inside a larger state machine. The option may be agreed while the NCP has not yet opened. IPCP may open while the route to the named server is broken. A packet may reach the address while no resolver answers. Every transition needs its own receipt.

Four matching shapes did not create one service

The four options look almost identical on the wire, but they do not name interchangeable authorities. DNS is the distributed domain-name system described by RFC 1034 and RFC 1035. NBNS belongs to the NetBIOS-over-TCP architecture described by RFC 1001 and RFC 1002. Sharing a request format reduced implementation work; it did not merge the namespaces, query rules, trust models or application expectations.

Primary and secondary values were negotiated independently. If both were present, RFC 1877 said the local peer should try the primary address before the secondary. That order defined a resolver-use preference at the endpoint. It did not say that the “primary DNS server” held a zone's master copy or that the “secondary” was synchronized with it. Those are different uses of familiar words at different control surfaces.

Independent negotiation also meant partial results were normal. A peer could accept a primary DNS address and reject the secondary. It could negotiate DNS while providing no NBNS information. It could propose two addresses in separate Naks that belonged to different configuration attempts. Treating the four options as one atomic bundle would manufacture agreement the packets never recorded.

Default absence was equally deliberate. RFC 1877 said no address was provided by default for each option. A missing option did not imply an unlimited resolver, an inherited address or a silent discovery mechanism. It recorded no agreement through this mechanism.

Topology decided whether the answer was useful

The memo declined to place these options in IPCP's recommended set. Its reason was unusually revealing: name-server information was useful only in relation to the remote network's topology and the local peer's application. A four-octet value could be well formed and mutually accepted yet useless from the path that resulted.

That sentence prevents a configuration ledger from becoming an outcome ledger. The remote peer controlled what it proposed. It might know a resolver suitable for callers on one access segment. The local endpoint controlled whether to request and retain the value. Routing then controlled whether packets could reach it. The server controlled whether and how it answered. Namespace authorities controlled the relevant data. The application decided whether to use DNS, NBNS, a local cache or some other source.

The current IANA PPP registry still lists options 129 through 132 against RFC 1877. That proves that the numeric meanings remain assigned. It does not prove that a present access server offers them, that a client requests them, that a negotiated address works or that any observed lookup used PPP-derived configuration.

RFC 1877 itself was Informational, not an Internet Standard, and it said security issues were not discussed. Neither fact can be stretched. Informational publication does not prove universal implementation. Silence on security does not authenticate the peer, the proposed resolver or the answers later returned.

The final receipt belonged to the application

A defensible trace begins with the raw IPCP exchange. It preserves packet identifiers, option numbers, proposed values, revised requests and exact acknowledgements. It then records the transition to IPCP Opened, interface and route installation, traffic sent to each negotiated address, query identifiers, replies, validation results, fallback choice and application outcome.

That ladder makes failure intelligible. A repeated zero request may mean the peer never supplies a value. Oscillating Naks may show two sides proposing incompatible policy. An Ack without Opened stops at configuration. An unreachable primary followed by a responsive secondary is a path and fallback event, not proof that “DNS was up” throughout. A valid response rejected by local policy is not a transport failure. A correct answer that the application ignores is not an application success.

RFC 1877's lasting design lesson lies in this modesty. It moved four useful addresses across a point-to-point control channel and gave each endpoint a way to agree on them. It did not ask that agreement to certify the network beyond the link. The negotiated address was a starting coordinate. Resolution still had to happen.