From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1551.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc1551.txt (limited to 'doc/rfc/rfc1551.txt') diff --git a/doc/rfc/rfc1551.txt b/doc/rfc/rfc1551.txt new file mode 100644 index 0000000..e800d4a --- /dev/null +++ b/doc/rfc/rfc1551.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group M. Allen +Request For Comments: 1551 Novell, Inc. +Obsoletes: RFC 1362 December 1993 +Category: Informational + + + Novell IPX Over Various WAN Media (IPXWAN) + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document describes how Novell IPX operates over various WAN + media. Specifically, it describes the common "IPX WAN" protocol + Novell uses to exchange necessary router to router information prior + to exchanging standard IPX routing information and traffic over WAN + datalinks. This document supercedes RFC 1362 and adds capability for + Unnumbered RIP links, On-demand statically routed links and client to + router connectivity. + +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 ......................................... 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.............................................. 22 + + + +Allen [Page 1] + +RFC 1551 IPXWAN December 1993 + + +1. Introduction + + This document describes how Novell IPX operates over various WAN + media. It is strongly motivated by a desire for IPX to treat ALL wide + area links in the same manner. Sections 3 and 4 describe this common + "IPX WAN" protocol. + + The IPX WAN protocol operation begins immediately after link + establishment. While IPX is a connectionless datagram protocol, WANs + are often connection-oriented. Different WANs have different methods + of link establishment. The subsections of section 1 of this document + describe what link establishment means to IPX for different media. + They also describe other WAN-media-dependent aspects of IPX + operation, such as protocol identification, frame encapsulation, and + link tear down. + +1.1 Operation Over PPP + + IPX uses PPP [1] when operating over point-to-point synchronous and + asynchronous networks. + + With PPP, link establishment means the IPX NCP [4] reaches the Open + state. NetWare IPX will negotiate 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. + + PPP allows either side of a connection to stop forwarding IPX if one + end sends an IPXCP or an LCP Terminate-Request. When a router detects + this, it will immediately reflect the lost connectivity in its + routing information database instead of 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 is used in the X.25 Call User Data field of + the Call Request frame, and indicates that the virtual circuit will + be devoted to IPX. + + Furthermore, each IPX packet is encapsulated directly in X.25 data + frame sequences without additional framing. + + Either side of the virtual circuit may close it, thereby tearing down + the IPX link. When a router detects this, it will immediately reflect + the lost connectivity in its routing information database instead of + + + +Allen [Page 2] + +RFC 1551 IPXWAN December 1993 + + + naturally aging it out. + +1.3 Operation over X.25 Permanent Virtual Circuits + + The nature of X.25 PVC's is that no call request is made. When the + router is informed that X.25 Layer 2 is up, the router 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 and re-perform the necessary steps to + obtain a full IPX connection. + +1.4 Operation over Frame Relay Permanent Virtual Circuits + + To determine when a permanent virtual circuit (PVC) has become active + or inactive, the router interacts periodically with either a private + Frame Relay switch or a public Frame Relay network. The method used + depends on the switch or service provider. Some support [7], section + 6l others support [3], Annex D. Novell supports both methods. + + When a router is restarted, IPXWAN exchanges over active Frame Relay + PVCs (that is, PVCs that have remained active before and after + 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 transitioned from an + inactive to an active state, link establishment is considered + complete and IPXWAN exchange over this newly activated link begins. + + When an active PVC becomes 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. + + + + + + + + +Allen [Page 3] + +RFC 1551 IPXWAN December 1993 + + +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. This number + will be a permanently assigned network number for the router. + Those readers familiar with NetWare 3.x servers should realize + that this is the "Internal" network number. + + Router Name: + + Every IPX WAN router must have a "Router Name". This is a symbolic + name given to the router. Its purpose is to allow routers to know + who they are connected to after link establishment - particularly + for network management purposes. A symbolic name conveys more + information to an operator than a set of numbers. 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 is useful if the client + connection software is configured with a symbolic name reflecting + the name of the client. This allows a router management utility to + determine which connection connects 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 dependant description, the IPXWAN protocol is + activated to exchange identities and determine certain operational + charactaristics 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 - as well as + + + +Allen [Page 4] + +RFC 1551 IPXWAN December 1993 + + + transmission of IPX data traffic. + +3.1 The Initial Negotiation + + The first exchange of packets decides the master/slave roles and the + routing protocol to be used on the link and gauges the link delay for + the routing metrics. The initial negotiation is the same for all + protocols. + + +---------------+ +---------------+ + | Timer Request | | Timer Request | + +---------------+ +---------------+ + \---->\ /<----/ + \ / + x + / \ + /\ /<----/ \---->\ /\ + / \ / \ + / \ / \ + / My primary \ / My primary \ + / network address\ / network address\ + \ is larger / \ is smaller / + \ / \ / + \ / \ / + \ / \ / + \/ \/ + MASTER SLAVE + + +----------------+ + <----------------+ Timer Response + + +----------------+ + + After link establishment, both sides of the link send Timer Request + packets and start a timer waiting for a Timer Response. These Timer + Requests are sent every 20 seconds until a response is received or a + descision is made that the remote node is not responding. This could + be after a predefined time (min. 60 seconds) or a number of retries + (e.g., 16). + + In composing the Timer Request, the router or workstation takes 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; + + + +Allen [Page 5] + +RFC 1551 IPXWAN December 1993 + + + - 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 do not have the + requirement to allocate a network number on a WAN link. This type of + routing protocol has the advantage of potentially simpler + configuration as no network number pools are necessary for WAN links. + However, these router implementations may still wish to interoperate + with the older IPXWAN implementations which are able to allocate + network numbers to the WAN link. In this 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. If this is the first time the work- + station is connecting to the router, the workstation will set the + WNodeID to zero indicating the router should be the link master and + allocate a network number for the new link. In this case, the work- + station will respond to the router's Timer Request and acknowledge + only the Workstation Routing Type option. Note that a workstation + does NOT include an Extended Node ID option in it's timer request. + + If the workstation is reconnecting a link after an earlier inactivity + disconnect, it is necessary for the workstation to be able to specify + its network, NIC address and "Router Name" field (so that file server + connections can be maintained after the reconnect). In this case, + the workstation will set its WNodeID field to FFFFFFFFh forcing + itself to be the link master. In this case, the router will respond + 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). + + + + + +Allen [Page 6] + +RFC 1551 IPXWAN December 1993 + + + On receiving a Timer Request packet, a router determines its role - + master or slave - for the remainder of the IPXWAN exchanges. The + master role does not denote special privileges, it merely means that + the router is the requestor in the ensuing request/response + exchanges. The descision is made as follows: + + 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 of slave. It + should compare the received WNodeID to that sent in it's own + Timer Request. + + The numeric comparisons are done by considering each byte of the + WNodeID or Extended Node ID fields as an unsigned integer, and the + first byte as most significant. + + The link slave responds to the Timer Request with a Timer Response. + To do so, each option in the received Timer Request is parsed. If an + option is not supported (or recognized), that option is rejected by + changing the WAccept field to "NO" for that option. + + When selecting the router type which will be used on the link, the + first option in the Timer Request which can be supported should be + accepted. All other router types should have the WAccept field set to + "NO". 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 be selected only if the other router supports + it and is able to assign the network number. This can be determined + by 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 wishes to provide WAN Client access without supporting + other WAN routing types, a potential problem arises since a router + and WAN client would both just be sending a single Routing Type + option indicating the use of WAN Client. The IPXWAN specification + + + +Allen [Page 7] + +RFC 1551 IPXWAN December 1993 + + + does not allow a WAN workstation to connect to another WAN + workstation. The method for detecting this is that the sent and + received Timer Requests have a single Routing Type defined of WAN + Client. To overcome this problem, IPXWAN defines that 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. This is so + that a workstation may detect that this is actually a router sending + the Timer Request and not just another workstation trying to call a + workstation. The extra option will serve to be a counted Routing Type + that will be ignored. If a workstation detects it is connecting to + another workstation, it should disconnect the link. + + Note that 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. Use of a single network for all clients is prefered, however, + 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 + allows a workstation which is reconnecting the ability to specify his + 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. Node numbers of zero or -1 are not allowed. + + If a slave determines it cannot support any of the supplied 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 is to be used as a common + network number for the new WAN link, and for calculating the RIP + transport time that will be advertized to other RIP routers for the + new link. This is calculated by stopping the timer which was started + when a Timer Request was initiated and applying the algorithm in + section 4.3. + + + + +Allen [Page 8] + +RFC 1551 IPXWAN December 1993 + + +3.2 Information Exchange + + After exchanging Timer Request packets, the link master and slave + have been determined, and the Routing Protocol to be used on the link + is negotiated. The link master is now responsible for sending an + Information Request packet to the slave specifying the network number + to be used on the new link (zero for unnumbered RIP and On Demand), + the calculated transport time to be used in the routing metric, the + Router Name (for management purposes), and for a workstation + connection, the NIC address the workstation will be adopting. The NIC + address option is a separate option added in the Information + Request/Response for workstation connectivity. It is NOT present for + router to router connections. + + If a router receives an inappropriate Information Request from a + workstation trying to set the common network number and NIC address + the router MUST overwrite these values with preferred values. When + the workstation receives the Information Response, it MUST note the + new values. If the workstation is unable to adjust to the new values, + it MUST issue a disconnect on the link. If a workstation is the link + master (i.e., it is reconnecting), the router is additionally + responsible for ensuring the "Router Name" field matches that of the + original connection. If the values differ, the call should be + disconnected. + + If a router detects an error for which no suitable protocol response + exists (e.g., unable to allocate a network number), the link should + be terminated according to the relevant media specification. + + Under certain circumstances, particularly on X.25 permanent circuits, + it is only possible to detect the remote router went away when it + comes back up again. In this case, one side of the link receives a + Timer Request packet when 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. + Furthermore, the routing information learned from this connection + should be immediately discarded. + + When Unnumbered RIP, On-demand or Workstation options are negotiated, + Information Request packets are repeated every 20 seconds until a + response is received. For the Numbered RIP links, the Information + Request is NOT resent. Instead, the link is disconnected after a + suitable delay (min. 60 seconds) - this requirement ensures + interoperabilty 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. + + + + +Allen [Page 9] + +RFC 1551 IPXWAN December 1993 + + +3.3 NAK Packets + + The IPXWAN protocol uses a NAK packet to indicate the received IPXWAN + packet was not 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 WPacketType is invalid or not recognized; + + - A badly formed IPXWAN packet is received. + + Returning a NAK packet allows the sender a chance to work out what + was wrong. If the sender was unable to determine 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 utilize the standard Novell IPX packet + format. The packets use the IPX defined packet type 04 defining a + Packet Exchange Packet. The 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 being a + local network of unknown number that requires no routing. This + feature is of use to us in transferring these packets before the + common network number is exchanged. Some routers need to know a "Node + Number" (or MAC address) for each node on a link. Node numbers will + be formed from the "WNode ID" field. The node number will be the 4 + bytes of WNode ID followed by 2 bytes of zero. For a workstation, the + node number will be 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 the references to vendor protocol description documents). + 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 undefined + + WOption Number assignment. These numbers only need to be assigned + from Novell for the "Timer Request" and "Timer Response" packets. + + + +Allen [Page 10] + +RFC 1551 IPXWAN December 1993 + + + Packet Types also need to be assigned by Novell. However, the options + within these packets are dependant on the "Router Type" 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 will not be described in this document since it + involves knowledge of 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 senders + 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 + + + +Allen [Page 11] + +RFC 1551 IPXWAN December 1993 + + + 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 as 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) | + +---------------------------------------------------------------+ + + + + +Allen [Page 12] + +RFC 1551 IPXWAN December 1993 + + +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: + The PAD option is used to fill the Timer Request up to the 576 byte + limit. This field will be of variable length depending on the number + of other options in the packet. This option will normally be the + last entry in the packet. Its sole purpose is to fill the IPX + packet to be 576 bytes. The pad option data should be filled with a + selection of totally random numbers to avoid compression modems or + PPP data compression from destroying 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, Timer Request packets are sent by both + sides of the link. Each end starts their sequence number at zero. + Subsequent retries (every 20 seconds) will increment the value of + this sequence number. Only a Timer Response packet with a sequence + number matching the last sent sequence number will be acted upon. + + + +Allen [Page 13] + +RFC 1551 IPXWAN December 1993 + + + 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. 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 not having 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 contained within 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 + to ALL other Router Types. This is the Router Type which is to be + + + +Allen [Page 14] + +RFC 1551 IPXWAN December 1993 + + + adopted by both ends of the link. Information exchanges will 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. This packet should ONLY be sent by the router or + workstation determining themselves 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. + + + +Allen [Page 15] + +RFC 1551 IPXWAN December 1993 + + + A workstation should replace the Router Name with the configured + name, or a constant descriptor string as described in section 2. + + For a Workstation Information Request, an extra option is added which + 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 having + a first byte with 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 is calculated by the link "Master". Link + Delay is specified in milli seconds. + + + +Allen [Page 16] + +RFC 1551 IPXWAN December 1993 + + + 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. This + packet should ONLY be sent by the router or workstation determining + themselves 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Allen [Page 17] + +RFC 1551 IPXWAN December 1993 + + +4.4 Information Response 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 | 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 contained within this packet are as described in + section 4.3. + + A link slave will additionally respond with the received NIC address + option as a confirmation of receipt. 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 contained 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. + + + + +Allen [Page 18] + +RFC 1551 IPXWAN December 1993 + + + 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 refers to the case where two WAN routers are + communicating using the RIP protocol across a link with NO physical + IPX network address. The premise for this ability is that there is no + need to address a packet 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 advantage to running unnumbered RIP links is that it is not + necessary to allocate/configure a pool of usable IPX network numbers + which can be used on the WAN links. The other advantage is that when + there is a large number of WAN links, it is not necessary to flood + the network with an unnecessary set 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 + do not need to periodically receive RIP and SAP broadcasts as they + play no part in the routing process. This allows routers to reduce + background traffic on the workstation link by not sending any + periodic RIP and SAP data. Note that it will not 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. + + It should also be noted that if multiple workstations are attached to + a single WAN workstation network (per router), broadcasts on that + network - whether originated from a workstation or the router - MUST + reach ALL other workstations. This will involve the router + duplicating the packet to all WAN workstation connections. + +7. On-demand, Statically Routed Links + + On-demand, Static Routing serves two purposes. The "on-demand" part + means that a router initiates communication to a destination only + when there is data to be forwarded to that destination. "Inititating + comunication" includes making a datalink call (where necessary) and + performing the IPXWAN exchange. A transient connection is closed + after a period of inactivity. + + + + + +Allen [Page 19] + +RFC 1551 IPXWAN December 1993 + + + The "static routing" part means that no routing information is 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; 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 proceeds 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 such media, 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. + + + + + + + + +Allen [Page 20] + +RFC 1551 IPXWAN December 1993 + + +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. + + + + + + + + + + + + + + +Allen [Page 21] + +RFC 1551 IPXWAN December 1993 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Allen [Page 22] + -- cgit v1.2.3