RFC 1552

The PPP Internetworking Packet Exchange Control Protocol (IPXCP)

📅 published December 1993, from ietf

RFC 1552: The PPP Internetwork Packet Exchange Control Protocol (IPXCP) 🎀

Okay bestie, here's the tea 📋. W. Simpson from Daydreamer wrote this one for the Network Working Group, and it's dated December 1993. It's a Standards Track doc ✨. The header doesn't list anything it obsoletes or updates, so there's no drama there 🙈.

Status of this Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check out the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌍.

Abstract 💜

Okay so the Point-to-Point Protocol (PPP) [1] gives you a way to send multi-protocol datagrams over point-to-point links 🔗. PPP defines an extensible Link Control Protocol, and it proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols 🧩.

The IPX protocol was originally used in Novell's NetWare products [3], and now loads of other vendors support it too 🏢. This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP 👑.

This memo is the product of the Point-to-Point Protocol Working Group of the IETF 🫶. Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list 💌.

Table of Contents 🍓

   1.  Introduction ...................................................2
   1.1 Specification of Requirements ..................................3
   1.2 Terminology ....................................................3
   2.  A PPP Network Control Protocol for IPX .........................4
   2.1 Sending IPX Datagrams ..........................................5
   2.2 IPX-WAN protocol ...............................................5
   2.3 Desired Parameters .............................................5
   2.4 Co-existence with IPX-WAN ......................................6
   3.  IPXCP Configuration Options ....................................6
   3.1 IPX-Network-Number .............................................7
   3.2 IPX-Node-Number ................................................8
   3.3 IPX-Compression-Protocol .......................................9
   3.4 IPX-Routing-Protocol ...........................................11
   3.5 IPX-Router-Name ................................................12
   3.6 IPX-Configuration-Complete .....................................13
   APPENDIX A. Link Delay and Throughput ..............................14
   SECURITY CONSIDERATIONS ............................................14
   REFERENCES .........................................................15
   ACKNOWLEDGEMENTS ...................................................15
   CHAIR'S ADDRESS ....................................................15
   AUTHOR'S ADDRESS ...................................................16

1. Introduction 🧚

PPP has three main components, bestie 🍓:

  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.

To get communications going over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link 💅. After the link is established and any optional facilities have been negotiated as needed by LCP, PPP must send IPXCP packets to choose and configure the IPX network-layer protocol 🎯. Once IPXCP has reached the Opened state, IPX datagrams can be sent over the link ✨.

The link stays configured for communications until explicit LCP or IPXCP packets close the link down, or until some external event happens (an inactivity timer expires or network administrator intervention) 🥱.

1.1 Specification of Requirements 💖

In this doc, a few words are used to signal the requirements of the spec, and they're often capitalized 🌈.

  • MUST 💅: this word, or the adjective "required", means the definition is an absolute requirement of the specification. No wiggle room, bestie.
  • MUST NOT 🚫: this phrase means the definition is an absolute prohibition of the specification. Big no-no.
  • SHOULD 🤔: this word, or the adjective "recommended", means there may be valid reasons in particular circumstances to ignore this item, but the full implications should be understood and carefully weighed before choosing a different course. So you can skip it sometimes, you just have to think it through first.
  • MAY 🫧: this word, or the adjective "optional", means this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. Translation: if you skip the optional bit, you still have to be ready to get along with someone who didn't.

1.2 Terminology 🧸

This document frequently uses the following terms 📖:

  • peer: the other end of the point-to-point link 🤝.
  • silently discard: this means the implementation discards the packet without any further processing 🗑️. It SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and it SHOULD record the event in a statistics counter 📊.
  • end-system: a user's machine 💻. It only sends packets to servers and other end-systems, and it doesn't pass any packets through itself 🙅.
  • router: allows packets to pass through, usually from one ethernet segment to another 🛣️. Sometimes these are called "intermediate-systems" 🚦.
  • half-router: two normal routers with an unnumbered link between them 🪞. Each looks like a router to the local users, but Netware doesn't understand unnumbered links, so each router is made to look like they both are a single machine 👯.

2. A PPP Network Control Protocol for IPX 🌸

The IPX Control Protocol (IPXCP) is responsible for configuring, enabling, and disabling the IPX protocol modules on both ends of the point-to-point link 🎛️. It uses the same packet exchange mechanism as the Link Control Protocol. IPXCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase, and any IPXCP packets received before that phase should be silently discarded 🗑️.

The IPX Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions 👯:

  • Frame Modifications: The packet may utilize any modifications to the basic frame format which have been negotiated during the Link Establishment phase 🖼️.
  • Data Link Layer Protocol Field: Exactly one IPXCP packet is encapsulated in the Information field of a PPP Data Link Layer frame where the Protocol field indicates type hex 802B (IPX Control Protocol) 📦.
  • Code field: Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects 🔢.
  • Timeouts: IPXCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time ⏳.
  • Configuration Option Types: IPXCP has a distinct set of Configuration Options 🧾.

2.1 Sending IPX Datagrams 📨

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

Exactly one IPX packet is encapsulated in the Information field of a PPP Data Link Layer frame where the Protocol field indicates type hex 002B (IPX datagram) 📬.

The maximum length of an IPX datagram transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. Since there is no standard method for fragmenting and reassembling IPX datagrams, PPP links supporting IPX MUST allow at least 576 octets in the information field of a data link layer frame 📏.

2.2 IPX-WAN protocol 🌐

A Novell specification called IPX-WAN [4] is intended to provide mechanisms similar to IPXCP negotiation over wide area links 🛰️. As viewed by PPP, IPX-WAN is a part of IPX, and IPX-WAN packets are indistinguishable from other IPX packets 🫥.

Currently, Novell has implemented IPXCP without any Configuration Options, and requires successful IPX-WAN completion, even when all required parameters have been hand configured. This makes it impossible for the current Novell products to interoperate with other IPXCP implementations which do not already include support for IPX-WAN 😩.

2.3 Desired Parameters 🎯

To resolve the possible conflict between the two configuration methods, this specification defines the concept of "Desired Parameters". Where applicable, each Configuration Option indicates the environment where the parameter which is negotiated MAY be required by the implementation for proper operation 🧠.

This determination is highly implementation dependent. For example, a particular implementation might require that all links have addresses, while another implementation might not need such addresses. The configuration negotiation is intended to discover that this pair of implementations will never converge 💔.

2.4 Co-existence with IPX-WAN 🤝

An IPXCP implementation which includes support for IPX-WAN SHOULD always reach Opened state, even when unable to negotiate some "Desired Parameter", and when no Configuration Options are successfully negotiated. This allows IPX-WAN the opportunity to finish the negotiation 🥰.

If an implementation does not include support for IPX-WAN, it SHOULD NOT reach Opened state when unable to negotiate some "Desired Parameter" 🙅.

IPX-WAN uses a "Timer Request" packet to set up the link. These MUST NOT be sent until IPXCP has Opened the link ⏰.

An implementation which provides both IPX-WAN and IPXCP Configuration Options capability SHOULD only send a Timer Request packet when a Timer Request packet is received, or upon failure to successfully negotiate a "Desired Parameter" 📤.

If unable to complete IPX-WAN setup when a "Desired Parameter" is unknown, by default IPXCP SHOULD terminate the link ✂️.

However, some implementations might be capable of operating without all indicated "Desired Parameters", in which case the termination MUST be configurable ⚙️.

3. IPXCP Configuration Options ⚙️

IPXCP Configuration Options allow modifications to the standard characteristics of the network-layer protocol to be negotiated. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed 🧁.

IPXCP uses the same Configuration Option format defined for LCP [1], with a separate set of Options 🧩.

Up-to-date values of the IPXCP Option Type field are specified in the most recent "Assigned Numbers" RFC [2]. Current values are assigned as follows 🔢:

1       IPX-Network-Number
2       IPX-Node-Number
3       IPX-Compression-Protocol
4       IPX-Routing-Protocol
5       IPX-Router-Name
6       IPX-Configuration-Complete
Section 3.1 is where things get juicy next, bestie 🎀

3.1 IPX-Network-Number 🎀

Description

Okay so this option is how the two ends of a link agree on which IPX network number they're using 🧚 An implementation can learn the number, or make sure both sides are on the same page. Agreement is everything, bestie 💖

The network number MUST be unique within the routing domain, or zero to indicate that it is not used for routing. No dupes allowed, periodt 💅

The sender of the Configure-Request says which network number they want. A network number of zero in a Configure-Request shall be interpreted as asking the peer to pick another value and send it back in a Configure-Nak, so it's basically "you choose, babe" 🙈 A network number of zero in a Configure-Ack shall be interpreted as agreeing that no value exists 🌸

Both ends of the link MUST have the same network number. If a Configure-Request comes in with a lower network number than the one configured locally, a Configure-Nak MUST be returned with the highest network number. Highest number wins, that's main character energy 👑

When the peer didn't include the option in its Configure-Request, the option SHOULD NOT be appended to a Configure-Nak. Don't add stuff nobody asked for 🙅

By default, no network number is assigned to the link, so the network number is zero. You don't need a network number if the interface isn't used by a routing protocol ✨

This is a Desired Parameter when the implementation is operating as a router. It MUST be negotiated if the network number is non-zero and was derived from another interface 🦋

Any IPX-WAN packets received MUST supercede information negotiated in this option. IPX-WAN always wins, no debate 💅

Here's the quick summary of the IPX-Network-Number Configuration Option format. The fields go out 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     |       IPX-Network-Number      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  IPX-Network-Number (cont.)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 1
  • Length: 6
  • IPX-Network-Number: The four octet IPX-Network-Number is the desired local IPX network number of the sender of the Configure-Request. This number may be zero, which is interpreted as being a local network of unknown number that is not used by the routing protocol 🌈

3.2 IPX-Node-Number 🧚

Description

This option lets the two ends negotiate the IPX node number for the local end of the link. An implementation can learn its own node number, or tell the peer what it is 💜

The node number MUST be unique for the network number. Unique node, unique vibes 🦋

The sender of the Configure-Request says which node number is desired. A node number of zero in a Configure-Request shall be interpreted as asking the peer to specify another value in a Configure-Nak. A node number of zero in a Configure-Ack shall be interpreted as agreeing that no value exists 🫶

If negotiating the peer's node number is required, and the peer didn't include the option in its Configure-Request, the option can be appended to a Configure-Nak. The value of the node number given MUST be acceptable as the peer IPX-Node-Number, or indicate with a zero value that the peer provide the information 🍓

By default, no node number is assigned to the link, so the node number is zero. You don't need a node number if the interface isn't used by a routing protocol 🌸

This is a Desired Parameter when the implementation is operating as an end-system. However, when the node number has been statically configured, this option SHOULD NOT be negotiated unless the peer asks for it 💅

Any IPX-WAN packets received MUST supercede information negotiated in this option. Same energy as before: IPX-WAN takes the crown 👑

Here's the IPX-Node-Number Configuration Option format at a glance. Fields go out 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     |       IPX-Node-Number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPX-Node-Number (cont.)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 2
  • Length: 8
  • IPX-Node-Number: The six octet IPX-Node-Number is the desired local IPX node number of the sender of the Configure-Request 🎀

3.3 IPX-Compression-Protocol 🌈

Description

This option lets the two ends negotiate a specific compression protocol. By default, compression is not enabled, so no squishing happens unless you ask for it 🙈

The sender of this Configuration Option says it can receive packets using the specified compression technique. A Configure-Ack MAY obligate the peer to send such packets, depending on the protocol negotiated 🔥

Information negotiated in this option MUST supercede any IPX-WAN packets received, since IPX-WAN packets could be affected by the compression technique. Compression gets the final say 💅

Here's the IPX-Compression-Protocol Configuration Option format. The fields go out 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     |   IPX-Compression-Protocol    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Data ...
      +-+-+-+-+
  • Type: 3
  • Length: >= 4
  • IPX-Compression-Protocol: The IPX-Compression-Protocol field is two octets and says which compression protocol is desired. Odd values for this field are always the same as the PPP Data Link Layer Protocol field values for that same compression protocol. Even values are used when the compression protocol is interleaved with IPX packets 💜

Up-to-date values of the IPX-Compression-Protocol field are specified in the most recent "Assigned Numbers" RFC [2]. Right now, the values are assigned like this 🧚

            Value (in hex)  Protocol

            0002            Telebit Compressed IPX
            0235            Shiva Compressed NCP/IPX
  • Data: The Data field is zero or more octets and contains additional data as determined by the particular compression protocol ✨

3.4 IPX-Routing-Protocol 💖

Description

This option lets the two ends negotiate a specific routing protocol, or no routing protocol at all if that's the vibe 🌸 The sender is saying it wants to receive information from the specified routing protocol. Multiple protocols MAY be requested by sending multiple IPX-Routing-Protocol Configuration Options. The "no routing protocol required" value is mutually exclusive with other values, so it's a solo act 🎀

By default, Novell's combination of Routing Information Protocol (RIP) and Server Advertising Protocol (SAP) is expected 👑

This is a Desired Parameter when the implementation is operating as an end-system, to indicate that no routing protocol is necessary 🍓

Any IPX-WAN packets received MAY add to information negotiated in this option. IPX-WAN can add to the party 🦋

Here's the IPX-Routing-Protocol Configuration Option format. Fields go out 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     |     IPX-Routing-Protocol      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Data ...
      +-+-+-+-+
  • Type: 4
  • Length: >= 4
  • IPX-Routing-Protocol: The IPX-Routing-Protocol field is two octets and says which type of Routing-Protocol is desired. This two octet quantity is sent most significant octet first 💅

Up-to-date values of the IPX-Routing-Protocol field are specified in the most recent "Assigned Numbers" RFC [2]. Current values are assigned as follows 🧚

      Value           Protocol

        0             No routing protocol required
        1             RESERVED
        2             Novell RIP/SAP required
        4             Novell NLSP required
  • Data: The Data field is zero or more octets and contains additional data as determined by the routing protocol indicated in the Routing-Protocol field 🌈

3.5 IPX-Router-Name ⭐

Description

This option is all about sharing the IPX server name, so the end system can show a friendly name in its interface 💅 The nature of this option is advisory only. It exists to make a simple user interface easier to build, nothing more. This option MUST NOT be included in a Configure-Nak. Not allowed in the Nak, no exceptions 🙅

Here's the IPX-Router-Name Option format. Fields go out 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     |           Name...            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 5
  • Length: >= 3
  • Name: This field contains the name of the IPX entity on this end of the link. The symbolic name should be between 1 and 47 ASCII characters in length, containing the characters 'A' through 'Z', underscore (_), hyphen (-) and "at" sign (@). The length of the name is bounded by the option length 🎀

On reception, the name SHOULD be padded to 48 characters using the NUL character. Those readers familiar with NetWare 3.x servers will realize that this is equivalent to the file server name. Nostalgia hits different 🌸

3.6. IPX-Configuration-Complete 🎀

Description

Okay bestie, this option is the "all my ducks are in a row" signal 🦋. It says that every implementation-dependent Desired Parameter is satisfied. It exists so you can figure out when convergence will happen in a heterogeneous environment (aka a mixed-vendor situation, which is lowkey chaotic 💀).

You SHOULD tuck this option into a Configure-Request when your statically configured parameters plus the Configuration Options you're offering will add up to a successful configuration 💅.

It's purely advisory, no pressure 🫶. You MUST NOT put this option in a Configure-Nak, periodt.

Implementation Note: If your implementation doesn't support IPX-WAN, you can instantly tell that link setup is doomed when a Desired Parameter is unknown, and this option is either missing from the peer's Configure-Request or gets Rejected by the peer. No waiting around for timeouts 😭.

If your implementation does support IPX-WAN, you can speed up link setup by skipping IPX-WAN entirely once this option has been Ack'd in both directions ⚡.

Totally valid to finish configuration without this option too, no drama 🌸. An implementation that includes the entire panoply of configuration options and IPX-WAN SHOULD interoperate with an implementation that doesn't support IPX-WAN or any configuration options (including this one), as long as the Desired Parameters are satisfied by default or hand configuration 🧚.

Here's the format summary for the IPX-Configuration-Complete Option. Fields go out left to right, like reading a text 💖.

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 6
  • Length: 2

So there's been some worry about estimating the link delay (measured in 55 millisecond ticks) that Novell routing protocols use. Lowkey important stuff 👑.

IPX-WAN uses its Timer Request and Reply for this. The measured delay gets multiplied by 6, because the measurement happens while the link is initializing and doesn't reflect actual loading 🙈.

Honestly, a better way is the PPP LCP Echo facility 💅. Stick a timestamp in the data part of the Request, then compare it with the same timer when the reply comes back. You could even use this to keep re-checking the real round trip delay as link and system loads shift. The echo packet size SHOULD be 576, matching the default IPX packet size.

If you don't have dynamic measurements, empirical evidence says the following is good enough:

                2,400 bps    134 ticks
               14,400 bps     21 ticks
               57,600 bps      5 ticks
                 >  1 Mbps     1 tick

Security Considerations 🚨

Plot twist: this memo does not discuss security issues at all. Not a word. Full stop.

References 📚

  • [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1548, Daydreamer, December 1993.
  • [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.
  • [3] Novell Inc., "NetWare System Interface Technical Overview", Novell Part Number 883-001143-001.
  • [4] Allen, M., "Novell IPX Over Various WAN Media", RFC 1551, Novell Inc., December 1993.
  • [5] Mathu, S., and M. Lewis, "Compressing IPX Headers Over WAN Media (CIPX)", RFC 1553, Telebit Corporation, December 1993.

Acknowledgments 💜

Some of the text here was borrowed from earlier docs made by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF) 🫶.

This doc grew out of drafts by these lovely people. Huge thanks for their work and for taking the first stab at the protocol ✨:

  • Michael Allen (mallen@novell.com)
  • Dave McCool (dave@shiva.com)
  • Robert D Vincent (bert@shiva.com)
  • Marty Del Vecchio (marty@shiva.com)

Chair's Address 🍓

If you want to reach the working group, go through the current chair:

   Fred Baker
   Advanced Computer Communications
   315 Bollay Drive
   Santa Barbara, California, 93111

   EMail: fbaker@acc.com

Author's Address 🦋

Questions about this memo can also be directed to:

   William Allen Simpson
   Daydreamer
   Computer Systems Consulting Services
   P O Box 6205
   East Lansing, MI  48826-6205

   EMail: Bill.Simpson@um.cc.umich.edu
📦 where this page comes from