RFC 1764

The PPP XNS IDP Control Protocol (XNSCP) 💖

• RFC: 1764
• Network Working Group 🌸
• Author: S. Senum (Steven J. Senum), DigiBoard 🧚
• Category: Standards Track 👑
• Date: March 1995 🎀
• Obsoletes or updates: nothing is listed in the title block 🫶

---

Status of this Memo 📜

Okay so this is an Internet standards track protocol for the Internet community, and the authors are literally asking everyone to discuss it and send suggestions for making it better 💅. For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited, so share it with everyone 🦋.

Abstract ✨

PPP [1] is the standard way to send multi-protocol datagrams over point-to-point links, bestie 🧚. It comes with an extensible Link Control Protocol, plus a whole family of Network Control Protocols for setting up and configuring different network-layer protocols 💜.

This document is the Network Control Protocol that sets up and configures the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP) over PPP 🔥.

Table of Contents 📋

1.     Introduction ..........................................    2
   1.1       Specification of Requirements ...................    2
   1.2       Terminology .....................................    3
2.     A PPP Network Control Protocol for XNS IDP ............    3
   2.1       Sending XNS IDP Datagrams .......................    4
SECURITY CONSIDERATIONS ......................................    5
REFERENCES ...................................................    5
   ACKNOWLEDGEMENTS ..........................................    5
CHAIR'S ADDRESS ..............................................    5
AUTHOR'S ADDRESS .............................................    5

1. Introduction 🫶

PPP has three main components, and they're all iconic 💅:

1. A method for encapsulating multi-protocol datagrams.
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols for establishing and configuring different network-layer protocols.

So here's the flow ✨. Each end of the PPP link has to send LCP packets first to configure and test the data link 🔧. After the link is up and any optional facilities have been negotiated the way LCP needs, PPP must send XNSCP packets to choose and configure the XNS IDP network-layer protocol. Once XNSCP reaches the Opened state, XNS IDP datagrams can be sent over the link 🚀.

The link stays configured for communications until explicit LCP or XNSCP packets close it down, or until some external event happens, like an inactivity timer expiring or a network administrator stepping in 💀.

1.1. Specification of Requirements 💖

In this document, a few words are used to signal the requirements of the spec. They're often capitalized, so watch for them 👀.

• MUST means the word, or the adjective "required", marks an absolute requirement of the specification. No ifs, no buts 🔒.
• MUST NOT means the definition is an absolute prohibition of the specification. Absolutely not 🙅‍♀️.
• SHOULD means the word, or the adjective "recommended", marks something there may be valid reasons to ignore in particular circumstances. Still, the full implications must be understood and carefully weighed before choosing a different course 🤔.
• MAY means the word, or the adjective "optional", marks one item in an allowed set of alternatives. An implementation that skips this option MUST still be prepared to interoperate with another implementation that does include it 🦋.

1.2. Terminology 🎀

This document uses these terms a lot, so let's get them down 📖:

• datagram is the unit of transmission in the network layer (such as IP). A datagram may be encapsulated in one or more packets passed to the data link layer 🌈.
• frame is the unit of transmission at the data link layer. A frame may include a header and/or a trailer, along with some number of units of data 🎁.
• packet is the basic unit of encapsulation, passed across the interface between the network layer and the data link layer. A packet is usually mapped to a frame. The exceptions are when data link layer fragmentation is being performed, or when multiple packets are packed into a single frame 🧩.
• peer is the other end of the point-to-point link 🫂.
• silently discard means the implementation discards the packet without any further processing. The implementation SHOULD provide the ability to log the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter 🤫.

2. A PPP Network Control Protocol for XNS IDP ✨

The XNS IDP Control Protocol (XNSCP) is in charge of configuring, enabling, and disabling the XNS IDP protocol modules on both ends of the point-to-point link 👑. It uses the same packet exchange mechanism as LCP. XNSCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase, and any XNSCP packets received before that phase should be silently discarded 🙅‍♀️.

XNSCP is exactly the same as LCP [1], with the following exceptions 💅:

Frame Modifications 🎀

The packet may use any modifications to the basic frame format that were negotiated during the Link Establishment phase 🦋.

Data Link Layer Protocol Field 🌸

Exactly one XNSCP packet is encapsulated in the Information field of a PPP Data Link Layer frame, and the PPP Protocol field indicates type hex 8025 (XNS IDP Control Protocol) 🔥.

Code field 💜

Only Codes 1 through 7 are used: Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject 🧚. Any other Codes should be treated as unrecognized, and they should result in Code-Rejects 🙈.

Timeouts ⏰

XNSCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be ready to wait for Authentication and Link Quality Determination to finish before timing out on a Configure-Ack or other response. It's suggested that an implementation give up only after user intervention or a configurable amount of time 🫶.

Configuration Option Types 🍓

XNSCP has no Configuration Options. Zero. None. Nada 💀.

2.1. Sending XNS IDP Datagrams 🦋

Before any XNS IDP packets can be communicated, PPP must reach the Network-Layer Protocol phase, and the XNS IDP Control Protocol must reach the Opened state 🚦.

Exactly one XNS IDP packet is encapsulated in the Information field of a PPP Data Link Layer frame, and the Protocol field indicates type hex 0025 (XNS IDP datagram) 🌈.

The maximum length of a XNS IDP datagram sent over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. There's no standard way to fragment and reassemble XNS IDP datagrams, though. So PPP links supporting XNS IDP MUST allow at least 576 octets in the Information field of a data link layer frame 🔒. That's a must-have, bestie 💖.

The format of the Information field itself is the same as the one defined in [2] ✨.

Security Considerations 🔐

Plot twist: this memo does not discuss security issues at all. Not even a little 😭. Keep that in mind as you read.

References 📚

[1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
    1661, Daydreamer, July 1994.

[2] Xerox, "Internet Transport Protocols", January 1991, Order No.
    XNSS 029101.

Acknowledgements 🫶

Some of the text in this document comes from earlier documents made by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF) 🌷.

In particular, Bill Simpson provided the boiler-plate used to create this document 🙌.

Chair's Address 🎀

The working group can be reached through the current chair 📮:

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

Phone: (805) 681-0115
EMail: fred@cisco.com

Author's Address 💜

Questions about this memo can also go to 💌:

Steven J. Senum
DigiBoard
6400 Flying Cloud Drive
Eden Prairie, Minnesota 55344

Phone: (612) 943-9020
EMail: sjs@digibd.com

That's the whole RFC, slay 🌈👑💅