RFC 1551
Novell IPX Over Various WAN Media (IPXWAN)
RFC 1551: Novell IPX Over Various WAN Media (IPXWAN) 🦋
Okay bestie, this is RFC 1551 💖 It's an Informational doc from the Network Working Group, written by M. Allen at Novell, Inc. and dated December 1993. Informational means it's sharing info with the Internet crowd, not an official standard 🌸 It also obsoletes RFC 1362 ✨ which means this one takes over from that earlier doc.
Status of this Memo 📝
This memo is here to provide information for the Internet community 🫶 It does not specify an Internet standard of any kind, so it's more of a vibe than a rulebook 💅 Distribution of this memo is unlimited, so you can share it with everyone ✨
Abstract 💜
So this doc explains how Novell IPX operates over various WAN media 🌐 The main thing is the common "IPX WAN" protocol. Novell uses it to swap the necessary router-to-router information before any standard IPX routing information and traffic go over WAN datalinks. This doc supersedes RFC 1362 and adds capability for Unnumbered RIP links, On-demand statically routed links, and client-to-router connectivity 🔥
Table of Contents 🗂️
Here's the whole map, bestie 🗺️
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 ......................................... 11
4.2 Timer Response Packet ........................................ 14
4.3 Information Request Packet ................................... 15
4.4 Information Response Packet .................................. 18
5. Running Unnumbered RIP ....................................... 19
6. Workstation Connectivity ..................................... 19
7. On-demand, Statically Routed Links ........................... 19
8. References ................................................... 21
9. Security Considerations ...................................... 21
10. Author's Address.............................................. 221. Introduction 🌈
So this doc is all about how Novell IPX runs over different WAN media 🌍 The whole big idea is that IPX should treat ALL wide area links in the same manner 😤 Sections 3 and 4 are where the common "IPX WAN" protocol lives 📦
The IPX WAN protocol kicks off right after link establishment 🔗 IPX is connectionless, but WANs are often connection-oriented, and different WANs have different ways of setting up links 🙃 The subsections of Section 1 explain what link establishment means to IPX for each medium. They also cover other media-dependent stuff like protocol identification, frame encapsulation, and link tear down 💅
1.1 Operation Over PPP 🎀
IPX uses PPP [1] when it's running over point-to-point synchronous and asynchronous networks 🧃
With PPP, link establishment means the IPX NCP [4] hits the Open state 🙌 NetWare IPX negotiates down to a null set of NCP options and uses normal frame encapsulation, the way PPP defines it.
Heads up, bestie 🚫 The IPXWAN protocol MUST NOT occur until the IPX NCP reaches the Open state. No jumping the gun!
Options negotiated by the IPXWAN protocol MUST supersede any options negotiated by the IPXCP 👑
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 just naturally aging it 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 🎯 That tells everyone the virtual circuit is devoted to IPX.
Each IPX packet is encapsulated directly in X.25 data frame sequences without any additional framing 🧵
Either side of the virtual circuit may 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 💖
X.25 PVCs don't make a call request, since that's just their nature 🤷♀️ When the router is informed that X.25 Layer 2 is up, it should assume that link establishment is complete ✅
Each IPX packet is encapsulated in an X.25 data frame sequence without additional framing 📦 Novell IPX assumes a particular X.25 permanent circuit is devoted to the use of IPX 🔒
If a router receives a layer 2 error condition (e.g., X.25 Restart), it should reflect lost connectivity for the permanent circuits in its routing information database 📉 Then it re-performs the necessary steps to get a full IPX connection back 🔁
1.4 Operation over Frame Relay Permanent Virtual Circuits 🌸
To figure out when a permanent virtual circuit (PVC) has gone active or inactive, the router checks in periodically with either a private Frame Relay switch or a public Frame Relay network 📡 Which method it uses 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 (that is, PVCs 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] without additional framing 🧵
When a router detects that a Frame Relay PVC has moved from inactive to active, link establishment is considered complete, and IPXWAN exchange over this 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 🧚
Additional WAN media will be added here as specifications are developed 🔮
2. Glossary Of Terms 📚
Primary Network Number
Every IPX WAN router has a "primary network number" 🌟 This is an IPX network number 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" 🏷️ It's a symbolic name given to the router, so routers can tell who they're connected to after link establishment, especially for network management purposes 🕵️♀️ A symbolic name tells an operator way more than a set of numbers ever could 🔢
The symbolic name should be between 1 and 47 characters in length, containing the characters 'A' through 'Z', underscore (_), hyphen (-), and "at" sign (@) 🔤 The string of characters should be followed by a null character (byte of zero) and padded to 48 characters using the null character 🧼 Those readers familiar with NetWare 3.x servers should realize that 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 reflecting the name of the client 💻 That 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 is used 🫶
3. IPX WAN Protocol Description ⚡
After the underlying data link connection is established, as described in the preceding media-dependent description, the IPXWAN protocol gets activated 🚀 Its job is to exchange identities and determine certain operational characteristics of the link 🪪
There are two steps in the 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 are concluded, transmission of IPX routing packets begins, using the routing protocol negotiated, and transmission of IPX data traffic begins too 🌊
3.1 The Initial Negotiation ✨
okay so the very first exchange of packets is the BIG one, bestie 💅 it decides who's the master and who's the slave, picks the routing protocol the link will use, and gauges the link delay for the routing metrics 🦋 and the initial negotiation is literally the same for every protocol, no cap 🫶
+---------------+ +---------------+
| Timer Request | | Timer Request |
+---------------+ +---------------+
\---->\ /<----/
\ /
x
/ \
/\ /<----/ \---->\ /\
/ \ / \
/ \ / \
/ My primary \ / My primary \
/ network address\ / network address\
\ is larger / \ is smaller /
\ / \ /
\ / \ /
\ / \ /
\/ \/
MASTER SLAVE
+----------------+
<----------------+ Timer Response +
+----------------+so after link establishment, both sides send Timer Request packets and start a timer waiting for a Timer Response ⏰ these Timer Requests keep going out every 20 seconds until a response shows up, or until somebody decides the remote node isn't responding 😭 that decision could be made after a predefined time (min. 60 seconds) or after a number of retries (e.g., 16) 💀
when the router or workstation is composing the Timer Request, it takes these into consideration 👀
- Which types of routing protocols it supports;
- Whether it is prepared to assign a network address to the link;
- For workstations, whether they require the ability to specify their network/NIC address on a reconnect;
- Whether it is able to support IPX header compression [6].
for each routing protocol supported, place 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) routing protocols don't need to allocate a network number on a WAN link, which is lowkey iconic because it means potentially simpler configuration with no network number pools needed for WAN links 🌸 BUT these router implementations might still wanna interoperate with the older IPXWAN implementations that CAN allocate network numbers to the WAN link 🥺 so in that case, the following method is used to force the older implementation to become the link master 🧚
It should be noted that 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 omits the Extended Node ID option ✨ on the other hand, 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 includes 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, periodt 💅 if this is the first time the workstation is connecting to the router, the workstation sets the WNodeID to zero, which tells the router it should 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 🫶 note that 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 maintained after the reconnect 🥹 so in this case the workstation sets its WNodeID field to FFFFFFFFh, which forces itself to be the link master ✨ and 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) 🔥
okay now the master/slave decision, which is giving very high-stakes energy 😤 on receiving a Timer Request packet, a router determines its role (master or slave) for the rest of the IPXWAN exchanges 💖 the master role does NOT mean special privileges, it just means the router is the requestor in the ensuing request/response exchanges 🌈 the decision goes like this:
- a) If there is an Extended Node ID present (and we understand the option), this must be compared to our Primary Network Number. If we have the lower Primary Network Number, we MUST respond with a Timer Response and become the slave.
- b) If there is NO Extended Node ID, we must compare the WNodeID of the received Timer Request with our Primary Network Number and respond if we have a lower number.
Note: The Primary Network Number for a workstation, when determining master/slave roles, depends on whether the workstation requires itself to be the master or slave. It should compare the received WNodeID to that 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 responds to the Timer Request with a Timer Response 💅 to do that, each option in the received Timer Request gets parsed. If an option isn't supported (or recognized), it gets rejected by changing the WAccept field to "NO" for that option 🙅♀️
when selecting the router type that will be used on the link, the first option in the Timer Request that can be supported should be accepted 👑 all other router types should have the WAccept field set to "NO" 💀 and a router MUST NOT accept workstation connectivity to a node which is another router 🫠
Note: It is permitted for a router to support a numbered routing type but not be able to assign the network number. In this case, that routing type can only be selected if the other router supports it AND is able to assign the network number. This can be figured out from the value of the received WNodeID field. If the router is unable to assign a network number to the link, it MUST support Unnumbered RIP and include this option in the Timer Requests. 🧩
if a router wants to provide WAN Client access without supporting other WAN routing types, there's a potential problem 😬 since the router and the WAN client would both just be sending a single Routing Type option indicating WAN Client. The IPXWAN specification does not let a WAN workstation connect to another WAN workstation. The way to detect this is that the sent and received Timer Requests each have a single Routing Type defined, which is WAN Client. To fix this, IPXWAN says a router MUST NOT send a single Routing Type if that type is just WAN Client 🙈 the router MUST additionally 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 this is actually a router sending the Timer Request, and not just another workstation trying to call a workstation ✨ the extra option serves as a counted Routing Type that gets ignored 🦋 and if a workstation detects it's connecting to another workstation, it should disconnect the link 🫶
Note: A router supporting a workstation will need to be able to supply AT LEAST one network number for workstations. All dial-in workstations could share the same network and be assigned unique node numbers by the router, or each workstation could be assigned a different network number. This is a router-specific implementation detail. Using a single network for all clients is preferred, though this does involve extra work by the router 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 is reconnecting specify its old network and NIC address. It is unlikely, with a 6 byte NIC address, that there will be wrap-around in the numbers that would cause a problem. 🌸
router Node Number allocation should follow a few simple rules 📋 the six byte NIC address SHOULD have the first byte set to 2:
Byte # +--1----2----3----4----5----6-+
| 02 | XX | XX | XX | XX | XX |
+-----------------------------+in an IEEE address space, this would represent a non-multicast, locally defined address 🤓 and node numbers of zero or -1 are not allowed 🚫
last but not least, if a slave determines it cannot support any of the routing protocols in the received Timer Request, it MUST issue a disconnect on the connection being established 💀 the master of the link (determined when a Timer Response packet is received) is responsible for defining the network number that will be used as a common network number for the new WAN link 👑 and it's also responsible for calculating the RIP transport time that will be advertised to other RIP routers for the new link ⏱️ this gets calculated by stopping the timer that was started when a Timer Request was initiated, and then 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 sorted 👑, and the Routing Protocol for the link gets negotiated too. Now the link master is in charge of sending an Information Request packet to the slave. That packet carries the network number for the new link (zero for unnumbered RIP and On Demand 🧚), the calculated transport time for the routing metric, the Router Name (for management, so it's giving admin energy 💅), and, for a workstation connection, the NIC address the workstation will be adopting 🎀. The NIC address option is its own separate option, added to the Information Request/Response 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 these values with preferred values. Main character router energy, fr 💅. When the workstation gets the Information Response, it MUST note the new values. If it can't adjust to them, it MUST issue a disconnect on the link. Also, if a workstation is the link master (aka it's reconnecting), the router is responsible for making sure the "Router Name" field matches the original connection. If the values differ, 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 💀.
Under certain circumstances, especially on X.25 permanent circuits, the only way to notice the remote router went away is when it comes back up again 🥀. So one side of the link receives a Timer Request packet while IPX is in a fully connected state. The side receiving the Timer Request MUST realize that a problem occurred, and revert to the IPX link establishment phase. On top of that, the routing information learned from this connection should be immediately discarded 🧹.
When Unnumbered RIP, On-demand or Workstation options are negotiated, Information Request packets get repeated every 20 seconds until a response is received ⏰. For Numbered RIP links, the Information Request is NOT resent. Instead, the link is disconnected after a suitable delay (min. 60 seconds). This requirement is there to keep interoperability with earlier versions of IPXWAN 🫶. When Information Requests are repeated, they should continue for a preconfigured time (min. 60 seconds) or a preconfigured number of retries (e.g., 16). Each retry uses an incremented sequence number 🔢.
3.3. NAK Packets 🙅
The IPXWAN protocol uses a NAK packet to say "nope, that IPXWAN packet wasn't acceptable." A NAK packet is an exact copy of the received packet with the WPacketType field set to NAK. There are two anticipated uses of this packet:
- The received
WPacketTypeis invalid or not recognized; - A badly formed IPXWAN packet is received.
Returning a NAK packet gives the sender a chance to work out what was wrong 🔍. If the sender can't figure 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. Socket number 0x9004 is a Novell reserved socket number for exclusive use with IPX WAN protocol exchange. IPX defines that a network number of zero (0) is interpreted as a local network of unknown number that requires no routing, and this is super useful 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 are 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 is explicitly assigned by the router and notified to the workstation in the Information Request packet.
Router Type number assignment. Other vendors' IPX routing protocols can make use of the IPXWAN protocol definition by obtaining 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" that gets negotiated. WOption numbers in these packets are then defined by the vendor defining 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 constructing the packet is a router. Note that an older version of IPXWAN will just reject this option and automatically become the link master, since the 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 🌸
Although more than one header compression option may be specified in a Timer Request packet, it is important that a MAXIMUM of ONE header compression option is 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 bestie, this one is literally the filler 🫶 The PAD option is used to top up the Timer Request to the 576 byte limit ✨ Its length is variable because it depends on how many other options are in the packet 🎀 This option will normally be the last entry in the packet. Its sole purpose is to make the IPX packet exactly 576 bytes 💖 The pad option data should be filled with totally random numbers, so that compression modems or PPP data compression can't wreck the link delay calculation 🙈 Note that this is different from the original RFC 1362 specification. This should not affect implementations 🦋 Implementations should not attempt to verify the contents of a PAD option 💅
+---------------------------------------------------------------+
| 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 will always be 576 bytes 🍓 However, there should be no assumption made about the number of options specified in this packet.
After link establishment, both sides of the link send Timer Request packets 🌈 Each end starts its sequence number at zero. Retries go out every 20 seconds, and each retry increments the sequence number. Only a Timer Response packet whose sequence number matches the last sent sequence number will be acted upon ✨
As mentioned earlier, the WNodeID field may be set to zero for a router if it is unable to provide 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 👑
Packets received on the reserved socket number that don't have the WIdentifier set to the hexadecimal 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 are as described in section 4.1. Any unknown options or not supported options within the Timer Request MUST have the WAccept Option set to NO in the Timer Response 🙅♀️
If the Timer Request packet contained more than one Router Type option and the "Slave" supports all the options, the "Slave" MUST set the WAccept Option to YES on the FIRST Router Type supported, and NO on ALL other Router Types 🔥 That first supported Router Type is the one both ends of the link adopt. Information exchanges then proceed by the link master, based on the accepted Router Type 💅
This packet must contain the same sequence number as the received Timer Request. It should ONLY be sent by the router or workstation that has determined itself to be the "Slave" of the link. (Workstations are ALWAYS the link slave 🧚)
Routers MUST set the WNodeID to their correct value when responding with the 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 replace the Router Name with its configured name, or a constant descriptor string as described in section 2 💖
For a Workstation Information Request, an extra option is added that specifies the NIC address for the workstation. In this case, the number of options will be 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 has a value other than 02 🦋
Calculation of link delay is performed as follows 🧮
// 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 a higher resolution timer is available, better results may be
obtained using the following algorithm:
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 used as the network transport time when advertized in the IPX RIP packet tuple for the network entry "Common Net #" 🚀 For a consistent network, a common link delay is required at both ends of the link, and it is calculated by the link "Master". Link Delay is specified in milli seconds ⏱️
The Common Net # is supplied by the link "Master". This number must be unique in the connected internetwork. Each WAN call requires a separate number 🌸 If the negotiated Router Type was Unnumbered RIP, On-demand, or NLSP, the specified Common Net # will be zero.
This packet should contain a sequence number starting at zero. It should ONLY be sent by the router or workstation that has determined itself to be the "Slave" of the link 🫶
If extra options are included in this packet, they should be silently discarded. If the information option is missing, the link MUST be disconnected 🚫
4.4 Information Response Packet 💖
okay so this is the reply to the Information Request, and it's giving full packet makeover 💅 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 are the same ones described in section 4.3 🫶
a link slave will additionally respond with the received NIC address option as a confirmation of receipt 🎀 and a workstation should replace the Router Name with the configured name, or a constant descriptor string as described in section 2 ✨
if the Information Request had an inappropriate Common Net # or NIC address, the Information Response may set new values 🙈 the receiver of the Information Response is responsible for checking on the value and terminating the connection if the new values cannot be used 💀
Routers MUST set the WNodeID to their correct value when sending an Information Response. A value of zero must NOT be used. 🚫
5. Running Unnumbered RIP 🦋
Unnumbered RIP is when two WAN routers talk RIP to each other across a link with NO physical IPX network address. The whole premise is that nothing needs to be addressed to anything on that WAN link 🌸 RIP and SAP run in exactly the same way as before, except the source and destination network numbers should be set to zero.
the perks are literally iconic 👑 you don't have to allocate or configure a pool of usable IPX network numbers for the WAN links, and when there are a ton of WAN links, the network doesn't get flooded with an unnecessary pile of extra RIP information.
6. Workstation Connectivity 🧚
Workstations MUST reside on a network and have a unique NIC address on that network to be individually addressable. However, workstations don't need to periodically receive RIP and SAP broadcasts because they play no part in the routing process 💖 this lets routers cut background traffic on the workstation link by not sending any periodic RIP and SAP data. Note that it won't cause a problem if the RIP and SAP is sent. It will just slow down the workstation access times.
RIP and SAP information should ONLY be sent if the workstation makes a specific request for information, like a service or route request 🍓
also, if multiple workstations are attached to a single WAN workstation network (per router), broadcasts on that network, whether they come from a workstation or the router, MUST reach ALL other workstations. that means the router duplicates the packet to all WAN workstation connections 🫶
7. On-demand, Statically Routed Links 🌈
okay so On-demand, Static Routing has two jobs 💅 the "on-demand" part means a router only starts talking to a destination when there's data to forward to that destination. "Inititating comunication" includes making a datalink call (where that's needed) and doing the IPXWAN exchange. A transient connection gets closed after a period of inactivity.
the "static routing" part means no routing information gets sent over the link. no RIP, no SAP, and no NLSP. instead, the router at each end is configured with the routes and services accessible through the link 🔥
with on-demand, static routing, the called router must be able to identify the calling router so that statically configured routes and services can be attached to that connection. for example, with X.25 switched virtual circuits, the calling DTE address can be used; with PPP, the PPP authentication can be used; after IPXWAN has completed, the "Router Name" can be used; and with a persistent datalink connection, the physical port identifier or a permanent virtual circuit identifier can be used. the choice of identifier is an implementation decision. whatever value the called router uses is called a Remote System Identifier, or RSI. for PPP links, Novell uses PPP PAP or CHAP authentication to determine the caller 🔑
a router implementing on-demand, static routing must maintain a database of RSIs, and lists describing the network numbers and services reachable through each RSI. these lists determine the reachability information it transmits to other routers in a routing area. other routers treat each on-demand, static routing link as though it were permanently available ✨
the on-demand exchange has a slight variation on the IPXWAN protocol. the differences are as follows:
in the Timer Request, the calling router offers only the "On-demand, static routing" Routing Type. if the called router is capable of On-demand static routing, it offers "On-demand, static routing" in the Timer Request, along with any additional routing types it is willing to support on the link. the Master/Slave election and choice of routing type proceed as described previously. if the Slave detects a mismatch in routing types, it disconnects the link 💀
for a persistent datalink (like X.25 PVCs), there may be no descerable "link establishemnt" event. for media like that, arrival of a Timer Request plays the role of detecting link establishment 🦋
as with Unnumbered RIP, there is no network number assigned to the link. NLSP Packets are not sent on the link. moreover, periodic RIP and SAP packets are not sent on the link. however, a router must respond to RIP and SAP queries received 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/nw_shell/ipxdocs/ipxrout.zip.
[6] Mathur, S., and M. Lewis, M., "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. Information on this document may be obtained by sending e-mail to dsink@novell.com.
9. Security Considerations 💀
Security issues are not discussed in this memo.
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: rfc1551 1993-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms