RFC 1634
Novell IPX Over Various WAN Media (IPXWAN)
Novell IPX Over Various WAN Media (IPXWAN) 💖
okay bestie, this one is RFC 1634, written by M. Allen at Novell, Inc. in May 1994 🌸 It's Informational category, and it obsoletes RFC 1551 and RFC 1362 🦋 Let's get into it.
Status of this Memo 📜
this memo gives info to the Internet community 💅 it does not specify an Internet standard of any kind, and it's unlimited for distribution 🌈
Abstract ✨
so this doc explains how Novell IPX works over different WAN media 🎀 the big star is the "IPX WAN" protocol, which is what routers use to swap necessary router-to-router info before they start trading standard IPX routing info and traffic over WAN datalinks 🔥 it supercedes RFC 1362 and RFC 1551. the changes from RFC 1551 fix some wording problem when an RFC 1362 router talks to an RFC 1551 router, and let numbers be used in a Router Name (main character energy for router names 🫶)
Table of Contents 🗂️
1. Introduction ................................................. 2
1.1 Operation Over PPP ........................................... 2
1.2 Operation Over X.25 Switched Virtual Circuits ................ 2
1.3 Operation Over X.25 Permanent Virtual Circuits ............... 3
1.4 Operation Over Frame Relay ................................... 3
1.5 Operation Over Other WAN Media ............................... 3
2. Glossary Of Terms ............................................ 4
3. IPX WAN Protocol Description ................................. 4
3.1 The Initial Negotiation ...................................... 5
3.2 Information Exchange ......................................... 9
3.3 NAK Packets .................................................. 10
4. Information Exchange Packet Formats .......................... 10
4.1 Timer Request Packet ......................................... 12
4.2 Timer Response Packet ........................................ 15
4.3 Information Request Packet ................................... 16
4.4 Information Response Packet .................................. 19
5. Running Unnumbered RIP ....................................... 20
6. Workstation Connectivity ..................................... 20
7. On-demand, Statically Routed Links ........................... 20
8. References ................................................... 22
9. Security Considerations ...................................... 22
10. Author's Address.............................................. 231. Introduction 🧚
this doc explains how IPX runs over different WAN media, and it's strongly motivated by wanting IPX to treat ALL wide area links the same way 💜 Sections 3 and 4 are where the common "IPX WAN" protocol lives.
the IPX WAN protocol kicks in right after the link is established 🍓 IPX is a connectionless datagram protocol, but WANs are often connection-oriented, and different WANs have different ways of setting up a link. so the subsections of section 1 spell out what link establishment means to IPX for each medium, plus other media-specific stuff like protocol identification, frame encapsulation, and link tear down 🌈
1.1 Operation Over PPP 🎀
IPX uses PPP [1] when it runs over point-to-point synchronous and asynchronous networks 🦋
with PPP, link establishment means the IPX NCP [4] reaches the Open state. NetWare IPX negotiates down to a null set of NCP options and uses normal frame encapsulation as defined by PPP 💅 The IPXWAN protocol MUST NOT occur until the IPX NCP reaches the Open state. Options negotiated by the IPXWAN protocol MUST supercede any options negotiated by the IPXCP. (yes, those capitals are doing the heavy lifting here, bestie 😭)
PPP lets either side stop forwarding IPX if one end sends an IPXCP or an LCP Terminate-Request. when a router notices this, it immediately reflects the lost connectivity in its routing information database instead of letting it naturally age out 💀
1.2 Operation over X.25 Switched Virtual Circuits 🔥
with X.25, link establishment means successfully opening an X.25 virtual circuit. As specified in RFC-1356, "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode" [2], the protocol identifier 0x800000008137 goes in the X.25 Call User Data field of the Call Request frame, and it signals that the virtual circuit is devoted to IPX 👑
also, each IPX packet gets encapsulated directly in X.25 data frame sequences with no extra framing ✨
either side of the virtual circuit can close it, which tears down the IPX link. when a router detects this, it immediately reflects the lost connectivity in its routing information database instead of naturally aging it out 🫶
1.3 Operation over X.25 Permanent Virtual Circuits 🌸
the thing about X.25 PVCs is that no call request is made 🙈 when the router is told that X.25 Layer 2 is up, the router should assume link establishment is complete.
each IPX packet is encapsulated in an X.25 data frame sequence with no extra framing. Novell IPX assumes a particular X.25 permanent circuit is devoted to IPX 🍓
if a router gets a layer 2 error condition (like X.25 Restart), it should reflect lost connectivity for the permanent circuits in its routing information database and redo the steps needed to get a full IPX connection again 🔁
1.4 Operation over Frame Relay Permanent Virtual Circuits 🦋
to figure out when a permanent virtual circuit (PVC) goes active or inactive, the router checks in periodically with either a private Frame Relay switch or a public Frame Relay network 🌐 the method depends on the switch or service provider. Some support [7], section 6l, others support [3], Annex D. Novell supports both methods 💖
when a router restarts, IPXWAN exchanges over active Frame Relay PVCs (the ones that stayed active before and after the restart) can begin immediately 🚀
each IPX packet is encapsulated in a Frame Relay frame sequence as defined in [3], with no extra framing ✨
when a router notices a Frame Relay PVC go from inactive to active, link establishment is considered complete and IPXWAN exchange over that newly activated link begins 🎉
when an active PVC goes inactive, the router reflects the lost connectivity in its routing information database 😭
1.5 Operation over other WAN media 🌈
more WAN media will be added here as specs get developed 🧚
2. Glossary Of Terms 📚
Primary Network Number:
Every IPX WAN router has a "primary network number" 👑 This is an IPX network number that's unique to the entire internet. It's a permanently assigned network number for the router. If you're familiar with NetWare 3.x servers, this is the "Internal" network number 💅
Router Name:
Every IPX WAN router MUST have a "Router Name"... wait, no, sorry, bestie, my bad 🙈 the original says "must" in lowercase, so it's a plain "must have" here 💜 The Router Name is a symbolic name given to the router. Its purpose is to let routers know who they're connected to after link establishment, especially for network management 🔥 a symbolic name tells an operator way more than a string of numbers does. The symbolic name should be between 1 and 47 characters long, using the characters A through Z, 0 through 9, underscore (_), hyphen (-), and "at" sign (@) ✨ the string should be followed by a null character (a byte of zero) and then padded out to 48 characters with that null character. If you're familiar with NetWare 3.x servers, the file server name is the Router Name 🎀
for workstation (client) connectivity, it's useful if the client connection software is configured with a symbolic name that reflects the client's name. this lets a router management utility figure out which connection goes with which client/router 🦋 if no name is configured, it is recommended that a default string such as "DIAL-IN-CLIENT" gets used 🫶
3. IPX WAN Protocol Description 🛠️
after the underlying data link connection is established (as described in the media-dependent section before this one), the IPXWAN protocol gets activated to swap identities and figure out certain operational characteristics of the link 💖
there are two steps in IPXWAN operation:
- Negotiating master/slave role and choice of routing protocol. The master/slave roles persist for the IPXWAN exchanges only;
- Information exchange of final router configuration.
after these steps wrap up, transmission of IPX routing packets begins, using the routing protocol that was negotiated, along with transmission of IPX data traffic 🔥
3.1 The Initial Negotiation
Okay bestie, the very first packets decide who's the master and who's the slave 👑, which routing protocol runs on the link 🛣️, and how long the link takes to respond (that's the delay, which feeds into the routing metrics ⏱️). Every protocol does this initial negotiation the same way ✨.
+---------------+ +---------------+
| Timer Request | | Timer Request |
+---------------+ +---------------+
\---->\ /<----/
\ /
x
/ \
/\ /<----/ \---->\ /\
/ \ / \
/ \ / \
/ My primary \ / My primary \
/ network address\ / network address\
\ is larger / \ is smaller /
\ / \ /
\ / \ /
\ / \ /
\/ \/
MASTER SLAVE
+----------------+
<----------------+ Timer Response +
+----------------+After the link is established, both sides send Timer Requests and start a timer waiting for a Timer Response 🎀. These Timer Requests go out every 20 seconds until a response shows up, or until a decision is made that the remote node isn't responding 🙈. That decision can come after a predefined time (min. 60 seconds) or after a number of retries (e.g., 16) 🔁.
When composing the Timer Request, the router or workstation thinks about:
- which types of routing protocols it supports;
- whether it's prepared to assign a network address to the link;
- for workstations, whether they need the ability to specify their network/NIC address on a reconnect;
- whether it's able to support IPX header compression [6].
For each routing protocol supported, put an option in the Timer Request packet. The Routing Type options should be added in the originator's order of preference, with the most preferred option first 💅.
Some of the newer (or modified) IPX routing protocols don't need to allocate a network number on a WAN link. That's a big vibe because it can mean simpler configuration, since no network number pools are needed for WAN links ✨. Still, these router implementations may want to interoperate with the older IPXWAN implementations that can allocate network numbers for the WAN link 🤝. In that case, the following method forces the older implementation to become the link master.
A router implementation capable of supporting workstation dial-in MUST be able to supply AT LEAST ONE network number on which the workstation can reside. 🚨
If the router is prepared to assign an IPX network number to the link, it sends its primary network number in the Timer Request WNodeID field and leaves out the Extended Node ID option 🧚. But if the router is not prepared to assign an IPX network number to the link, it sets the Timer Request WNodeID field to zero and puts its primary network number in an Extended Node ID option 💖.
Workstations follow a similar but slightly different set of rules for setting the WNodeID field 🥰. If this is the first time the workstation is connecting to the router, it sets the WNodeID to zero, which tells the router to be the link master and allocate a network number for the new link. In this case, the workstation responds to the router's Timer Request and acknowledges only the Workstation Routing Type option. Also, a workstation does not include an Extended Node ID option in its Timer Request.
If the workstation is reconnecting a link after an earlier inactivity disconnect, it needs to be able to specify its network, NIC address and "Router Name" field, so that file server connections can be kept alive after the reconnect 🖥️. In this case, the workstation sets its WNodeID field to FFFFFFFFh, which forces itself to be the link master. Here, the router responds to the workstation's Timer Request with only the Workstation Router Type acknowledged.
Further packets in the IPXWAN exchange MUST use the correct WNodeID (workstations will always use zero) 🔐.
When a router receives a Timer Request packet, it works out its role, master or slave, for the rest of the IPXWAN exchanges 🧠. The master role doesn't mean special privileges. It just means the router is the requestor in the request/response exchanges that follow. The decision goes like this:
- a) If the WNodeID field is zero in both the sent and the received Timer Requests:
- i) If both Timer Requests include an Extended Node ID, the router with the higher numeric value of this field is the Master. If the two Extended Node ID fields are equal, a configuration error has occurred. After reporting the error, the router issues a disconnect on the underlying data-link connection. Manual intervention is needed to fix the error condition 🛑.
- ii) If only one Timer Request includes the Extended Node ID, the router sending it is the Master.
- iii) If neither Timer Request includes the Extended Node ID, a connection can't be established. The data-link circuit is cleared by the system that started it 🙅.
- b) If either the sent or the received Timer Request (or both) contains a nonzero WNodeID field, the router with the higher WNodeID is the Master.
- c) If the two WNodeID fields are equal and nonzero, a configuration error has occurred. After reporting the error, the router issues a disconnect on the underlying data-link connection. Manual intervention is needed to fix the error condition 🛑.
Note: The Primary Network Number a workstation uses when working out master/slave roles depends on whether the workstation requires itself to be the master or the slave. It should compare the received WNodeID to the one sent in its own Timer Request 🤓.
The numeric comparisons are done by treating each byte of the WNodeID or Extended Node ID fields as an unsigned integer, with the first byte as the most significant one 🔢.
The link slave answers the Timer Request with a Timer Response 💌. To do that, it parses each option in the received Timer Request. If an option isn't supported (or recognized), the slave rejects it by changing the WAccept field to "NO" for that option 🙅♀️.
When picking the router type that will be used on the link, the first option in the Timer Request that can be supported should be accepted. Every other router type gets the WAccept field set to "NO" 💅. A router MUST NOT accept workstation connectivity to a node that's another router 🚫.
Note: It's allowed for a router to support a numbered routing type but not be able to assign the network number. In that case, that routing type can only be selected if the other router supports it and is able to assign the network number. You can tell this from the value of the received WNodeID field 🕵️♀️. If the router can't assign a network number to the link, it MUST support Unnumbered RIP and include this option in the Timer Requests 🎀.
Now here's a tricky one 😭. If a router wants to provide WAN Client access without supporting any other WAN routing types, things get messy, because the router and the WAN client would both just send a single Routing Type option, which says WAN Client. IPXWAN doesn't allow a WAN workstation to connect to another WAN workstation. The way to detect this is when the sent and received Timer Requests each have a single Routing Type defined, and that type is WAN Client. To fix it, IPXWAN says a router MUST NOT send a single Routing Type if that type is just WAN Client 🚫. The router MUST also include one (or more) of the defined routing types (like WAN RIP) with the WAccept option set to NO 🧩. That way, a workstation can tell it's really a router sending the Timer Request and not just another workstation trying to call it. The extra option counts as a Routing Type that gets ignored 🫶. If a workstation finds out it's connected to another workstation, it should disconnect the link.
A router supporting a workstation needs to be able to supply AT LEAST one network number for workstations 🌈. All dial-in workstations could share the same network and get unique node numbers from the router, or each workstation could get its own network number. That's a router-specific implementation detail. Using a single network for all clients is preferred, but it means the router has extra work to do when dealing with broadcast frames 📡. When the router is the link master and allocating NIC addresses on a single network, it should ALWAYS use a unique value, by incrementing the NIC address for each client connection 🔼. This lets a workstation that's reconnecting specify its old network and NIC address. With a 6 byte NIC address, wrap-around in the numbers is unlikely to cause a problem 🙏. Router Node Number allocation should follow a few simple rules. The six byte NIC address SHOULD have its first byte set to 2 🌸.
Byte # +--1----2----3----4----5----6-+
| 02 | XX | XX | XX | XX | XX |
+-----------------------------+In an IEEE address space, this represents a non-multicast, locally defined address 💜. Node numbers of zero or -1 are not allowed 🙅♀️.
If a slave decides it can't support any of the routing protocols offered in the received Timer Request, it MUST issue a disconnect on the connection being established 😤. The master of the link (figured out when a Timer Response packet is received) is in charge of defining the network number that will be the common network number for the new WAN link. It's also responsible for calculating the RIP transport time that gets advertised to other RIP routers for the new link ⏳. That's worked out by stopping the timer that started when the Timer Request was initiated and applying the algorithm in section 4.3 🦋.
3.2. Information Exchange ✨
okay so once the Timer Request packets have been swapped, the link master and slave are officially decided 👑 and the routing protocol for the link gets negotiated too. Next up, the link master has to send an Information Request packet to the slave. This packet is where the network number for the new link gets set (it's zero for unnumbered RIP and On Demand 🧚), plus the calculated transport time for the routing metric, the Router Name (for management purposes 📋), and, if it's a workstation connection, the NIC address the workstation is going to adopt 💻. The NIC address option is its own separate option, added to the Information Request/Response exchange just for workstation connectivity. It is NOT present for router to router connections 🙅♀️.
If a router gets an inappropriate Information Request from a workstation that's trying to set the common network number and NIC address, the router MUST overwrite those values with preferred ones 💅. When the workstation gets the Information Response, it MUST note the new values 📝. If the workstation can't adjust to them, it MUST issue a disconnect on the link 💀. And if a workstation is the link master (aka it's reconnecting), the router also has to make sure the "Router Name" field matches the one from the original connection 🔍. If the values don't match, the call should be disconnected.
If a router runs into an error that has no suitable protocol response (like being unable to allocate a network number 😭), the link should be terminated according to the relevant media specification.
Here's a tricky one 👀. Especially on X.25 permanent circuits, the only way to tell that the remote router went away is when it comes back up again. So in this case, one side of the link gets a Timer Request packet while IPX is in a fully connected state. The side that receives that Timer Request MUST realize something went wrong, and revert to the IPX link establishment phase 🔄.
Also, any routing information learned from this connection should be immediately discarded 🗑️.
Now about the retries 🔁. When Unnumbered RIP, On-demand or Workstation options are negotiated, Information Request packets get repeated every 20 seconds until a response shows up. For Numbered RIP links, the Information Request is NOT resent. Instead, the link gets disconnected after a suitable delay (min. 60 seconds). That requirement is there to make sure things still work with earlier versions of IPXWAN 🫶. When Information Requests are repeated, they should keep going for a preconfigured time (min. 60 seconds) or a preconfigured number of retries (e.g., 16). And each retry uses an incremented sequence number 🔢.
3.3. NAK Packets
The IPXWAN protocol uses a NAK packet to say "nope, that packet wasn't acceptable" 🙅♀️. A NAK packet is an exact copy of the received packet, just with the WPacketType field set to NAK. There are two anticipated uses for it:
- The received
WPacketTypeis invalid or not recognized 🤨; - A badly formed IPXWAN packet is received 🙈.
Sending a NAK gives the sender a chance to figure out what went wrong, which is honestly such a good move 🧠. If the sender still can't work out the problem, the call can then be disconnected 📞.
The value of the NAK WPacketType is FFh ✨.
4. Information Exchange Packet Formats 🎀
All IPX WAN protocol exchanges use the standard Novell IPX packet format 💖. The packets use the IPX defined packet type 04, which is a Packet Exchange Packet. The socket number 0x9004 is a Novell reserved socket number that's used exclusively for IPX WAN protocol exchange 🔐. IPX defines that a network number of zero (0) means a local network of unknown number that requires no routing 🧚. This comes in clutch for sending these packets before the common network number has been exchanged 🙌. Some routers need to know a "Node Number" (or MAC address) for each node on a link 🌸. Node numbers get formed from the "WNode ID" field. The node number is the 4 bytes of WNode ID followed by 2 bytes of zero. For a workstation, the node number gets explicitly assigned by the router and then notified to the workstation in the Information Request packet 💻.
Router Type number assignment. Other vendors' IPX routing protocols can use the IPXWAN protocol definition by getting Router Types from Novell 🦋. This document will then include the new Router Types (with references to the vendor protocol description documents). The current Routing Types are:
00 Numbered RIP/SAP
01 NLSP (no RIP/SAP - defined in [8])
02 Unnumbered RIP/SAP
03 On Demand, static routing (no RIP/SAP or NLSP)
04 Workstation (no RIP/SAP)
05-FF Currently undefinedWOption Number assignment. These numbers only need to be assigned from Novell for the "Timer Request" and "Timer Response" packets 🔢.
Packet Types also need to be assigned by Novell 🫶. However, the options within these packets depend on the "Router Type" negotiated 👀. WOption numbers in these packets are then defined by the vendor that defines the Routing Type. The same packet format should still be maintained 💅.
Router Type 01 won't be described in this document, since it involves knowing the NLSP protocol to implement 🙃. Please refer to [8] for a complete specification of these NLSP IPXWAN exchanges and the NLSP protocol 📖.
4.1. Timer Request Packet 💜
+---------------------------------------------------------------+
| Checksum | FF FF | Always FFFF |
| Packet Length | 02 40 | Max IPX size (576 bytes|
| | | Hi Lo order) |
| Trans Control | 00 | Hops traversed |
| Packet Type | 04 | Packet Exchange Packet |
| Dest Net # | 00 00 00 00 | Local Network |
| Dest Node # | FF FF FF FF FF FF | Broadcast |
| Dest Socket # | 90 04 | Reserved WAN socket |
| Source Net # | 00 00 00 00 | Local Network |
| Source Node # | 00 00 00 00 00 00 | Set to zero |
| Source Socket # | 90 04 | Reserved WAN socket |
|------------------+-------------------+------------------------|
| WIdentifier | 57 41 53 4D | Confidence identifier |
| WPacket Type | 00 | Timer Request |
| WNode ID | xx xx xx xx | Primary Net # of |
| | | sending router |
| | | (Hi Lo order) |
| WSequence # | xx | Sequence start at 0 |
| WNum Options | xx | Number of options |
|------------------+-------------------+------------------------|
| WOption Number | xx | Option Identifier |
| WAccept Option | xx | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | xx xx | Number of following |
| | | option bytes (Hi Lo) |
| WOption Data | nn | Option specific data |
+---------------------------------------------------------------+Routing Type Option 🛣️
One or more of the following router type options should be included in a Timer Request packet 🧩. A router should ALWAYS include Routing Type zero (0) if full interoperability is required with an older implementation 🙏. The router types MUST be included in the sender's order of preference 📶. If a router receives a Timer Response with more than one Router Type having WAccept set to Yes, the link MUST be disconnected 🚫.
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 00 | IPX RIP/SAP Routing |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 01 | NLSP |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 02 | Unnumbered RIP/SAP |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 03 | On-demand, static Rting|
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 04 | Client - No RIP/SAP |
| | | except on request |
+---------------------------------------------------------------+Extended Node ID Option 🪪
The extended node ID should only be included if the WNodeID field is set to zero AND the node building the packet is a router 🤓. Heads up: an older version of IPXWAN will just reject this option and automatically become the link master, since WNodeID is zero 👑.
+---------------------------------------------------------------+
| WOption Number | 04 | Extended Node ID |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 04 | Pad data length (Hi Lo)|
| WOption Data | xx xx xx xx | Real primary network # |
| | | of this router (Hi-Lo) |
+---------------------------------------------------------------+Header Compression Option 🗜️
Even though more than one header compression option can be specified in a Timer Request packet, it's super important that a MAXIMUM of ONE header compression option gets accepted 🚨. If an implementation receives a Timer Response with more than one header compression option with the accept option set to Yes, the link MUST be disconnected 💥. [Ref 6] defines the full Telebit Header Compression method 📚.
+---------------------------------------------------------------+
| WOption Number | 80 | Header Compression |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 03 | Variable - at least 1 |
| WOption Data | 00 | 0 = Telebit Hdr Compr. |
| | xx | Compression Options |
| | xx | Compression Slots |
+---------------------------------------------------------------+PAD Option: 🎀
okay so the PAD option is literally just filler bestie 🫶 its whole job is to stuff the Timer Request up to the 576 byte limit. How long it is depends on how many other options are in the packet, and it's normally the very last thing in there. ✨
The pad data should be totally random numbers 🎲 The reason is that compression modems or PPP data compression could squish a predictable pattern and totally wreck the link delay calculation 😭 Also, this is different from the original RFC 1362 spec, but it shouldn't break anything for implementers 💅 And implementations should not try to check what's inside a PAD option. Let it be!
+---------------------------------------------------------------+
| WOption Number | FF | Pad option |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | xx xx | Pad data length (Hi Lo)|
| | | (enough to fill packet)|
| WOption Data | Random numbers | |
+---------------------------------------------------------------+Note: Timer Request packets are ALWAYS 576 bytes, no matter what 🍓 But you should not assume anything about how many options are in there.
After the link is up, both sides send Timer Request packets 🦋 Each end starts its sequence number at zero. If there's no reply, retries go out every 20 seconds and the sequence number goes up each time. Only a Timer Response whose sequence number matches the last one sent will actually get acted upon. Anything else is ignored, no drama 🙈
Also, a router can set the WNodeID to zero if it can't come up with a network number for the link. BUT if a router ONLY supports the Numbered RIP/SAP option, it MUST be capable of proving a network number for a WAN link. No excuses bestie 👑
Packets that show up on the reserved socket number without the WIdentifier set to the hex values noted above should be discarded 🗑️✨
4.2. Timer Response Packet 💅
+---------------------------------------------------------------+
| Checksum | FF FF | Always FFFF |
| Packet Length | 02 40 | Max IPX size (576 bytes|
| | | Hi Lo order) |
| Trans Control | 00 | Hops traversed |
| Packet Type | 04 | Packet Exchange Packet |
| Dest Net # | 00 00 00 00 | Local Network |
| Dest Node # | FF FF FF FF FF FF | Broadcast |
| Dest Socket # | 90 04 | Reserved WAN socket |
| Source Net # | 00 00 00 00 | Local Network |
| Source Node # | 00 00 00 00 00 00 | Set to zero |
| Source Socket # | 90 04 | Reserved WAN socket |
|------------------+-------------------+------------------------|
| WIdentifier | 57 41 53 4D | Confidence identifier |
| WPacket Type | 01 | Timer Response |
| WNode ID | xx xx xx xx | Primary Net # of |
| | | sending router |
| | | (Hi Lo order) |
| WSequence # | xx | Same as Timer Request |
| | | received |
| WNum Options | xx | Number of options |
|------------------+-------------------+------------------------|
| WOption Number | xx | Option Identifier |
| WAccept Option | xx | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | xx xx | Number of following |
| | | option bytes (Hi Lo) |
| WOption Data | nn | Option specific data |
+---------------------------------------------------------------+The options in this packet work exactly like the ones described in section 4.1 🌸 Any unknown or unsupported options in the Timer Request MUST have the WAccept Option set to NO in the Timer Response. Rude, but fair 🙅♀️
Here's the tea ☕ If the Timer Request had more than one Router Type option and the "Slave" supports all of them, the "Slave" MUST set the WAccept Option to YES on the FIRST Router Type it supports, and NO on ALL the other Router Types. That one is the Router Type both ends of the link will adopt 🧚 After that, the link master runs the information exchanges based on the accepted Router Type.
This packet must contain the same sequence number as the Timer Request it's answering. It should ONLY be sent by the router or workstation that figured out it's the "Slave" of the link. (Workstations are ALWAYS the link slave, iykyk 💖)
Routers MUST set the WNodeID to their correct value when they respond with a Timer Response. A value of zero must NOT be used 🔥
4.3. Information Request Packet 🧚
+---------------------------------------------------------------+
| Checksum | FF FF | Always FFFF |
| Packet Length | 00 63 | Size of header+data |
| | | (Hi Lo order) |
| Trans Control | 00 | Hops traversed |
| Packet Type | 04 | Packet Exchange Packet |
| Dest Net # | 00 00 00 00 | Local Network |
| Dest Node # | FF FF FF FF FF FF | Broadcast |
| Dest Socket # | 90 04 | Reserved WAN socket |
| Source Net # | 00 00 00 00 | Local Network |
| Source Node # | 00 00 00 00 00 00 | Set to zero |
| Source Socket # | 90 04 | Reserved WAN socket |
|------------------+-------------------+------------------------|
| WIdentifier | 57 41 53 4D | Confidence identifier |
| WPacket Type | 02 | Information Request |
| WNode ID | xx xx xx xx | Primary Net # of |
| | | sending router |
| | | (Hi Lo order) |
| WSequence # | 00 | Sequence start at 0 |
| WNum Options | 01 | 1 Option to follow |
| WOption Number | 01 | Define IPX RIP/SAP |
| | | info exchange |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 36 | Option length (Hi Lo) |
| WOption Data | | |
| Link Delay | xx xx | Hi Lo link delay in |
| | | milli seconds (see |
| | | below for calculation) |
| Common Net # | xx xx xx xx | Hi Lo Common Network # |
| Router Name | xx (x 48 decimal) | Router name - as defned|
| | | in section 2. |
+---------------------------------------------------------------+Routers MUST set the WNodeID to their correct value when sending an Information Request. A value of zero must NOT be used 🙅♀️
A workstation should swap the Router Name for its configured name, or a constant descriptor string like the one described in section 2 🎀
For a Workstation Information Request, there's an extra option that carries the NIC address for the workstation 🦋 In that case, the number of options is set to two (2).
+---------------------------------------------------------------+
| WOption Number | 05 | Define NIC Address |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 06 | Option length (Hi Lo) |
| WOption Data | 02 xx xx xx xx xx | NIC Address for W/S |
+---------------------------------------------------------------+Routers or workstations should not refuse to use a NIC address whose first byte is something other than 02 💅
Now for the math, because it's giving science class 🧪 Here's how the link delay gets calculated:
// Start_time is a time stamp when Timer Request sent out
// End_time is a time stamp when a Timer Response is
// received.
link_delay = end_time - start_time; // 1/18th second
if (link_delay < 1)
{
link_delay = 1;
}/*IF*/
// We are on a slow net, so add some biasing to help stop
// multiple workstation sessions timing out on the link
link_delay *= 6; /* Add the biasing for multiple sessions */
link_delay *= 55; /* Convert link delay to milliseconds */If you've got a higher resolution timer, you can get better results with this version:
conversion_factor = number of timer units in 1/18th second;
link_delay = ((end_time - start_time) * 6) / conversion_factor;
if (link_delay == 0)
{
link_delay = 1;
}/*IF*/
link_delay *= 55; /* Convert link delay to milliseconds */The "Link Delay" is what gets used as the network transport time when it's advertised in the IPX RIP packet tuple for the "Common Net #" network entry ⏱️ For a consistent network, both ends of the link need the same link delay, and the link "Master" is the one who calculates it. Link Delay is specified in milliseconds, bestie 💜
The Common Net # comes from the link "Master" ✨ This number must be unique across the connected internetwork. Every WAN call needs its own separate number. If the negotiated Router Type was Unnumbered RIP, On-demand, or NLSP, then the specified Common Net # is zero 🌈
This packet should contain a sequence number starting at zero. It should ONLY be sent by the router or workstation that determined it's the "Slave" of the link 🫶
If extra options are included in this packet, they should be silently discarded. And if the information option is missing, the link MUST be disconnected 💀
4.4. Information Response Packet ✨
Okay bestie, the Information Response is basically the reply to the Information Request. Here's the layout 🎀
+---------------------------------------------------------------+
| Checksum | FF FF | Always FFFF |
| Packet Length | 00 63 | Size of header+data |
| | | (Hi Lo Order) |
| Trans Control | 00 | Hops traversed |
| Packet Type | 04 | Packet Exchange Packet |
| Dest Net # | 00 00 00 00 | Local Network |
| Dest Node # | FF FF FF FF FF FF | Broadcast |
| Dest Socket # | 90 04 | Reserved WAN socket |
| Source Net # | 00 00 00 00 | Local Network |
| Source Node # | 00 00 00 00 00 00 | Set to zero |
| Source Socket # | 90 04 | Reserved WAN socket |
|------------------+-------------------+------------------------|
| WIdentifier | 57 41 53 4D | Confidence identifier |
| WPacket Type | 03 | Information Response |
| WNode ID | xx xx xx xx | Primary Net # of |
| | | sending router |
| | | (Hi Lo order) |
| WSequence # | 00 | Same as Info Request |
| WNum Options | 01 | 1 Option to follow |
| WOption Number | 01 | Define IPX RIP/SAP |
| | | info exchange |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 36 | Option length (Hi Lo) |
| WOption Data | | |
| Link Delay | xx xx | Hi Lo link delay (as |
| | | received in Info Requ) |
| Common Net # | xx xx xx xx | Hi Lo Common Network # |
| | | (as received in Info |
| | | request) |
| Router Name | xx (x 48 decimal) | Router name - as defned|
| | | in section 2. |
+---------------------------------------------------------------+The responses inside this packet work exactly the way they do in section 4.3, so no new surprises there 💅
A link slave will also send back the NIC address option it received, as proof that it got the message 🫶 A workstation should swap the Router Name for its configured name, or a constant descriptor string, like we talked about in section 2 🌸 Now, if the Information Request had a wonky Common Net # or NIC address, the Information Response is allowed to set new values. The receiver has to check those values, and if they can't be used, it's on them to terminate the connection 😭
The receiver is the one checking the new values, so don't just accept them blindly, bestie 🙈
Routers MUST set the WNodeID to their correct value when they send an Information Response 🔥 And a value of zero must NOT be used. Zero is a no-go, period 💀
5. Running Unnumbered RIP 🦋
Unnumbered RIP is when two WAN routers talk RIP over a link that has NO physical IPX network address at all 🌈 The whole idea works because nothing on that WAN link needs to be addressed. RIP and SAP run exactly the same way as always, except the source and destination network numbers get set to zero. Iconic, simple, done ✨
There are two big perks here. First, you don't have to allocate or configure a pool of usable IPX network numbers just for the WAN links 🎀 Second, if you've got a ton of WAN links, you don't flood the network with a pile of extra RIP information 💜
6. Workstation Connectivity 💻
Workstations MUST live on a network and have a unique NIC address on that network so they can be individually addressed 🫶 The good news is that workstations don't need RIP and SAP broadcasts on a regular schedule, since they don't play any part in routing. That means routers can cut background traffic on the workstation link by not sending any periodic RIP and SAP data 🍓 Sending it anyway won't break anything, it'll just slow down the workstation's access times, so bestie, don't do that 😭
RIP and SAP information should ONLY be sent when the workstation specifically asks for it, like with a service request or a route request 🧚
Also, if a bunch of workstations hang off one WAN workstation network (per router), broadcasts on that network MUST reach ALL the other workstations. That's whether the broadcast came from a workstation or from the router itself. To make that happen, the router duplicates the packet onto every WAN workstation connection 🌸
7. On-demand, Statically Routed Links 🌙
On-demand, static routing has two jobs, and they're both giving main character energy 👑 The "on-demand" part means a router only starts talking to a destination when there's actual data to forward to it. "Starting communication" includes making a datalink call (where that's needed) and running the IPXWAN exchange 📞 After a stretch of inactivity, the transient connection gets closed 💤
The "static routing" part means no routing info gets sent over the link at all: no RIP, no SAP, and no NLSP 🙅♀️ Instead, the router on each end is manually configured with the routes and services it can reach through that link 🧠
Here's the tricky bit. With on-demand static routing, the called router has to be able to tell who's calling, so it can attach the right statically configured routes and services to that connection 🔍 Depending on the setup, that could be the calling DTE address for X.25 switched virtual circuits, the PPP authentication for PPP, the "Router Name" once IPXWAN is done, or the physical port identifier or permanent virtual circuit identifier for a persistent datalink. Which identifier you pick is an implementation decision 💅 Whatever value the called router uses gets called a Remote System Identifier, or RSI. For PPP links, Novell uses PPP PAP or CHAP authentication to figure out who the caller is 🔐
A router doing on-demand static routing MUST NOT... well, scratch that. What it must do is keep a database of RSIs, plus lists of the network numbers and services reachable through each RSI. Those lists decide what reachability info it passes along to the other routers in a routing area 🗺️ Meanwhile, the other routers treat each on-demand static link as if it were always available 🫶
The on-demand exchange is a slightly different flavour of IPXWAN. Here's how it differs 👇
In the Timer Request, the calling router only offers the "On-demand, static routing" Routing Type. If the called router can do on-demand static routing too, it offers "On-demand, static routing" in its Timer Request, along with any other routing types it's willing to support on the link 🎀 The Master/Slave election and routing type choice then go the same way as described earlier. If the Slave spots a mismatch in routing types, it disconnects the link 💀
For a persistent datalink, like X.25 PVCs, there might not be any noticeable "link establishment" event 🙈 For that kind of media, the arrival of a Timer Request is what counts as detecting that the link has been established ✨
Last thing: just like with Unnumbered RIP, no network number is assigned to the link. NLSP Packets aren't sent on it, and periodic RIP and SAP packets aren't sent on it either 🙅♀️ However, a router must respond to RIP and SAP queries that come in on the link 💖
8. References 📚
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links", RFC 1548, Daydreamer, December 1993.
[2] Malis, A., Robinson, D., and R. Ullman, "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, August 1992.
[3] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1490, Wellfleet Communications, Inc., Ascom Timeplex, Inc., July 1993.
[4] Simpson, W., "The PPP Internetwork Packet Exchange Control Protocol (IPXCP)", RFC 1552, Daydreamer, December 1993.
[5] Novell IPX Router Specification. Novell Part Number 107-000029-001. This document may be retrieved via Anonymous FTP to SJF-LWP (130.57.11.140) under /sys/ftpguest/dev_docs/ipx_rtr/ipxrtr.zip
[6] Mathur, S., and M. Lewis, "Compressing IPX Headers Over WAN Media (CIPX)", RFC 1553, Telebit Corporation, December 1993.
[7] ANSI, "Integrated Services Digital Network (ISDN) - Digital Subscriber Signalling System Number 1 (DSS1) - Signalling Specification for Frame Relay", ANSI T1.617-1991, June 1991.
[8] Novell NetWare Link Services Protocol (NLSP) Specification. Novell part number 100-001708-002. This document may be retrieved via Anonymous FTP to SJF-LWP (130.57.11.140) under /sys/ftpguest/dev_docs/ipx_rtr/nlsp.zip.
9. Security Considerations 🔒
Security issues are not discussed in this memo.
Yikes, bestie. The memo itself says security issues are not discussed in it, so don't assume anything about security from this document alone 💀
10. Author's Address 💌
Michael Allen
Novell, Inc.
2180 Fortune Drive
San Jose, CA 95131
EMail: mallen@novell.com
The working group can be contacted via the current chair:
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California, 93111
EMail: fbaker@acc.com📦 where this page comes from
- ietf: rfc1634 1994-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms