RFC 1877

PPP Internet Protocol Control Protocol Extensions for Name Server Addresses

📅 published December 1995, from ietf

PPP Internet Protocol Control Protocol Extensions for Name Server Addresses 🎀

RFC number: 1877 🦋
Written by: S. Cobb (that's Steve Cobb, at Microsoft) 💻
Working group: Network Working Group 🌸
Category: Informational ✨
Date: December 1995 📅
Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🤷

Status of This Memo 📜

Okay bestie, this memo is an info drop for the Internet community 💅. It does not specify an Internet standard of any kind, so it's not a standard. Distribution of this memo is unlimited 🌈.

Abstract 💭

So PPP [1] is the go-to standard way to shove multi-protocol datagrams across point-to-point links 🚀. It has an extensible Link Control Protocol plus a whole family of Network Control Protocols (NCPs) for setting up and configuring different network-layer protocols. This doc extends the NCP for IP over PPP [2] so the two ends can negotiate primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server (NBNS) [4] addresses 💖.

Table of Contents 🧚

     1.     Additional IPCP Configuration options .................    1
        1.1         Primary DNS Server Address ....................    2
        1.2         Primary NBNS Server Address ...................    3
        1.3         Secondary DNS Server Address ..................    4
        1.4         Secondary NBNS Server Address .................    5
     REFRENCES ....................................................    6
     SECURITY CONSIDERATIONS ......................................    6
     CHAIR'S ADDRESS ..............................................    6
     AUTHOR'S ADDRESS .............................................    6

1. Additional IPCP Configuration Options ✨

The four name server address configuration options, 129 to 132, give you a way to get the addresses of Domain Name System (DNS) servers and (NetBIOS Name Server (NBNS) nodes on the remote network 🌐.

Primary and secondary addresses are negotiated independently 🙌. They serve identical purposes, except that when both are present an attempt SHOULD be made to resolve names using the primary address before using the secondary address.

These options are designed to match option 3 (IP-Address) in format and behavior, which is already in most IPCP implementations. That makes life easier for implementers 🫶.

Since name server info only helps depending on the topology of the remote network and the local peer's application, it's suggested that these options not be added to the "IPCP Recommended Options" list 🙈.

1.1. Primary DNS Server Address

Description

This Configuration Option lets the two peers negotiate the address of the primary DNS server to be used on the local end of the link 🧚. If the local peer asks for an invalid server address (which it will typically do on purpose 😏), the remote peer NAKs this option and sends back the IP address of a valid DNS server 💅.

By default, no primary DNS address is provided 🌸.

Here's what the Primary DNS Address Configuration Option looks like. The fields go left to right 👀.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |      Primary-DNS-Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Primary-DNS-Address (cont)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 129
Length: 6
Primary-DNS-Address: The four octet Primary-DNS-Address is the address of the primary DNS server to be used by the local peer. If all four octets are set to zero, it's an explicit request for the peer to provide the address info in a Config-Nak packet 🥺.
Default: No address is provided.

1.2. Primary NBNS Server Address

Description

This Configuration Option lets the two peers negotiate the address of the primary NBNS server to be used on the local end of the link 🦋. If the local peer asks for an invalid server address (which it will typically do on purpose 😏), the remote peer NAKs this option and sends back the IP address of a valid NBNS server 💖.

By default, no primary NBNS address is provided ✨.

Here's the Primary NBNS Address Configuration Option format. Again, left to right 🫶.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |      Primary-NBNS-Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Primary-NBNS-Address (cont)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 130
Length: 6
Primary-NBNS-Address: The four octet Primary-NBNS-Address is the address of the primary NBNS server to be used by the local peer. If all four octets are set to zero, it's an explicit request for the peer to provide the address info in a Config-Nak packet 🥺.
Default: No address is provided.

1.3. Secondary DNS Server Address

Description

This Configuration Option lets the two peers negotiate the address of the secondary DNS server to be used on the local end of the link 🌸. If the local peer asks for an invalid server address (which it will typically do on purpose 😏), the remote peer NAKs this option and sends back the IP address of a valid DNS server 🧚.

By default, no secondary DNS address is provided 🙈.

The Secondary DNS Address Configuration Option format, left to right as always 💅:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |      Secondary-DNS-Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Secondary-DNS-Address (cont) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 131
Length: 6
Secondary-DNS-Address: The four octet Secondary-DNS-Address is the address of the primary NBNS server to be used by the local peer. If all four octets are set to zero, it's an explicit request for the peer to provide the address info in a Config-Nak packet 🥺.
Default: No address is provided.

Quick heads up, bestie: the original says "primary NBNS server" right here, in the Secondary-DNS-Address field description. That looks like a typo, but I've kept the wording exactly as written 🙈

1.4. Secondary NBNS Server Address

Description

This Configuration Option lets the two peers negotiate the address of the secondary NBNS server to be used on the local end of the link 🦋. If the local peer asks for an invalid server address (which it will typically do on purpose 😏), the remote peer NAKs this option and sends back the IP address of a valid NBNS server 👑.

By default, no secondary NBNS address is provided ✨.

Last format, same left-to-right energy 🫶:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |      Secondary-NBNS-Address
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Secondary-NBNS-Address (cont) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: 132
Length: 6
Secondary-NBNS-Address: The four octet Secondary-NBNS-Address is the address of the secondary NBNS server to be used by the local peer. If all four octets are set to zero, it's an explicit request for the peer to provide the address info in a Config-Nak packet 🥺.
Default: No address is provided.

References 📚

[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.
[2] McGregor, G., "PPP Internet Control Protocol", RFC 1332, Merit, May 1992.
[3] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002, March 1987.
[4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
[5] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

Two more things I noticed in the original and left alone: the table of contents spells it REFRENCES, and the in-text citations [3] and [4] point to DNS and NBNS, while the reference list has [3] as the NetBIOS service spec and [4] as the Domain Names concepts doc. Also, [5] is listed but never cited in the text 🤓

Security Considerations 🔐

Security issues are not discussed in this memo. 💀

Chair's Address 🪑

The working group can be contacted via the current chair:

   Fred Baker
   Cisco Systems
   519 Lado Drive
   Santa Barbara, California  93111

   EMail: fred@cisco.com

Author's Address 💌

Questions about this memo can also be directed to:

   Steve Cobb
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399

   Phone: (206) 882-8080

   EMail: stevec@microsoft.com

📦 where this page comes from

ietf: rfc1877 1995-12
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms