As per Relevance of the word september, we have this rfc below:
Network Working Group M.
Request for Comments: 1362 Novell, Inc
September 1992
Novell IPX Over Various WAN Media (IPXWAN
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This document describes how Novell IPX operates over various
media. Specifically, it describes the common "IPX WAN"
Novell uses to exchange necessary router to router information
to exchanging standard IPX routing information and traffic over
datalinks
Table of
1. Introduction ................................................. 1
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 .............. 2
1.4. Operation Over Frame Relay .................................. 3
1.5. Operation Over Other WAN Media .............................. 3
2. Glossary Of Terms ............................................ 3
3. IPX WAN Protocol Description ................................. 4
4. Information Exchange Packet Formats .......................... 5
4.1. Timer Request Packet ........................................ 6
4.2. Timer Response Packet ....................................... 8
4.3. Information Request Packet .................................. 10
4.4. Information Response Packet ................................. 12
5. References ................................................... 12
6. Security Considerations ...................................... 13
7. Author's Address.............................................. 13
1.
This document describes how Novell IPX operates over various
media. It is strongly motivated by a desire for IPX to treat ALL
area links in the same manner. Sections 3 and 4 describe this
"IPX WAN" protocol
Allen [Page 1]
RFC 1362 IPXWAN September 1992
IPX WAN protocol operation begins immediately after
establishment. While IPX is a connectionless datagram protocol,
are often connection-oriented. Different WANs have different
of link establishment. The subsections of section 1 of this
describe what link establishment means to IPX for different media
They also describe other WAN-media-dependent aspects of
operation, such as protocol identification, frame encapsulation,
link tear down
1.1 Operation Over
IPX uses PPP [1] when operating over point-to-point synchronous
asynchronous networks
With PPP, link establishment means the IPX NCP [4] reaches the
state. NetWare IPX will reject all NCP options, and uses normal
encapsulation as defined by PPP. The IPXWAN protocol MUST NOT
until the IPX NCP reaches the Open state
PPP allows either side of a connection to stop forwarding IPX if
end sends an IPXCP or an LCP Terminate-Request. When a router
this, it will immediately reflect the lost connectivity in
routing information database instead of naturally aging it out
1.2 Operation over X.25 Switched Virtual
With X.25, link establishment means successfully opening an X.25
virtual circuit. As specified in RFC-1356, "
Interconnect on X.25 and ISDN in the Packet Mode" [2], the
identifier 0x800000008137 is used in the X.25 Call User Data field
the Call Request frame, and indicates that the virtual circuit
be devoted to IPX
Furthermore, each IPX packet is encapsulated directly in X.25
frame sequences without additional framing
Either side of the virtual circuit may close it, thereby tearing
the IPX link. When a router detects this, it will immediately
the lost connectivity in its routing information database instead
naturally aging it out
1.3 Operation over X.25 Permanent Virtual
The nature of X.25 PVC's is that no call request is made. When
router is informed that X.25 Layer 2 is up, the router should
that link establishment is complete
Allen [Page 2]
RFC 1362 IPXWAN September 1992
Each IPX packet is encapsulated in an X.25 data frame
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
routing information database and re-perform the necessary steps
obtain a full IPX connection
1.4 Operation over Frame
Novell conforms to RFC-1294, "Multiprotocol Interconnect over
Relay" [3] for frame relay service and packet encapsulation
Currently, Novell has not stabilized the method for treating
relay connections - whether they treat the connections as LANs
WANs
1.5 Operation over other WAN
Additional WAN media will be added here as specifications
developed
2. Glossary Of
Primary Network Number
Every IPX WAN router has a "primary network number". This is
IPX network number unique to the entire internet. This
will be a permanently assigned network number for the router
Those readers familiar with NetWare 3.x servers should
that this is the "Internal" network number
Router Name
Every IPX WAN router must have a "Router Name". This is a
name given to the router. Its purpose is to allow routers to
who they are connected to after link establishment -
for network management purposes. A symbolic name conveys
information to an operator than a set of numbers. The
name should be between 1 and 47 characters in length
the characters 'A' through 'Z', underscore (_), hyphen (-)
"at" sign (@). The string of characters should be followed by
null character (byte of zero) and padded to 48 characters
the null character. Those readers familiar with NetWare 3.
servers should realize that the file server name is the
Name
Allen [Page 3]
RFC 1362 IPXWAN September 1992
3. IPX WAN Protocol
IPX WAN links have the concept of a LINK MASTER and a LINK SLAVE
This relationship is decided upon based on information
within the first IPX packets transferred across the WAN link
After link establishment, both sides of the link send "Timer Request
packets and start a timer waiting for a "Timer Response".
"Timer Request" packets are sent every 20 seconds until a response
received or a time-out occurs trying to initialize a connection (
timer is restarted each time a new "Timer Request" is sent).
time-out should be configurable, and is normally about one minute
This is directly dependent on the call setup time for the connection
If a time-out occurs, the router issues a disconnect on the
connection and optionally attempts to retry the connection
When a "Timer Request" is received, the router with the
primary network number MUST respond with a "Timer Response" packet -
and become the "Slave" of the link. If the "Slave" determines that
cannot support any of the Routing Types included in the "
Request" packet, the "Slave" should issue a disconnect on
connection being established. The "Master" of the link (
when a "Timer Response" packet is received) is responsible
defining the network number that is to be used as a common
number for the new WAN link, and for calculating the RIP
time that will be advertized to other RIP routers for the new link
This is calculated by stopping the timer which was started when
"Timer Request" was initiated and applying the algorithm in
4.2.
To allow this, both sides of the link MUST have an adequate pool
WAN network numbers (unique within the internetwork) available to
assigned to the link when the call is fully completed. The "Master
of the link MUST then select a network number and construct
"Information Request" packet containing the calculated link delay
the common network number, and its own router name. On receiving
packet, the "Slave" MUST turn the packet around, overwrite the
name and node identifier and send an "Information Response".
After the "Master" has received the "Information Response" and
"Slave" has received the "Information Request", standard IPX RIP
SAP packets are transferred across the WAN link, as currently
for LAN links. The "IPX Router Specification" [5]
information describing the Novell RIP/SAP protocol for third
developers
Note that the "Information Request" and "Information Response
packets are specific to the "Routing Type"=0 information exchanges
Allen [Page 4]
RFC 1362 IPXWAN September 1992
With this routing type, no retransmission is made of any of
Information packets. If a response has not been received within
predefined time-out period, a disconnect is issued on the link,
the link can optionally be attempted later
If a router detects an error for which no suitable protocol
exists (e.g., unable to allocate a network number), the link
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
comes back up again. In this case, one side of the link receives
Timer Request packet when IPX is in a fully connected state.
side receiving the Timer Request MUST realize that a
occurred, and revert to the IPX link establishment phase
Furthermore, the routing information learned from this
should be immediately discarded
4. Information Exchange Packet
All IPX WAN information exchange packets conform to the
Novell IPX packet format. The packets use the IPX defined packet
04 defining a Packet Exchange Packet. The socket number 0x9004 is
Novell reserved socket number for exclusive use with IPX
information exchange. IPX defines that a network number of 0
interpreted as being a local network of unknown number that
no routing. This feature is of use to us in transferring
packets before the common network number is exchanged. Some
need to know a "Node Number" (or MAC address) for each node on
link. Node numbers will be formed from the "WNode ID" field.
node number will be the 4 bytes of WNode ID followed by 2 bytes
zero
Router Type number assignment. Other vendors IPX routing
can make use of the IPXWAN protocol definition by obtaining
Types from Novell. This document will then include the new
Types (with the references to vendor protocol description documents).
WOption Number assignment. These numbers only need to be
from Novell for the "Timer Request" and "Timer Response" packets
Other packet types (e.g., the "Information Request" packets,
dependent on the "Router Type" negotiated and can contain any (
defined) packet type other than 0 or 1. WOption numbers in
packets are then defined by the vendor defining the Routing Type.
same packet format should still be maintained
Allen [Page 5]
RFC 1362 IPXWAN September 1992
4.1 Timer Request
+---------------------------------------------------------------+
| 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 | 02 | 2 Options follow |
| 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 | FF | Pad option |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic
| WOption Data Len | 02 0E | Pad data length (Hi Lo)|
| WOption Data | 00->FF's | Repeated sequence of 00|
| | | through FF's. |
+---------------------------------------------------------------+
Note
Timer Request packets will always be 576 bytes. However
there should be no assumption made about the number
options specified in this packet
After link establishment, Timer Request packets are sent by
sides of the link. Each end starts their sequence number at zero
Subsequent retries (every 20 seconds) will increment the value
this sequence number. Only a Timer Response packet with a
number matching the last sent sequence number will be acted upon
When receiving this packet, the WNode ID should be compared to
receiver's Primary Network #. If the WNode ID is larger than
receiver's Primary Network #, a Timer Response packet should be sent
and the receiver should become the link "Slave".
Allen [Page 6]
RFC 1362 IPXWAN September 1992
Packets received on the reserved socket number not having
WIdentifier set to the hexadecimal values noted above should
discarded
Routing Type Option
A routing type of zero (0) is the minimum
requirement (as defined by this document). A router ready to send
Timer Response (and receiving a routing type of zero) MUST
with a routing type of zero. A router ready to send a Timer
(and receiving routing types not matching a supported value)
respond with a Routing Type of zero indicating support for
minimum common protocol
Note that multiple Routing Type Options can be included in the
Request packet if the router supports multiple routing methods
IPX. The included Router Types MUST include and support this
zero option
Accept Option (for Routing Type and PAD options):
This field MUST be set to YES if the option is supported, and NO
an option is not supported. A Timer Response MUST respond with
one Router Type set to YES
PAD Option
This option will normally be the last entry in the packet. Its
purpose is to fill the IPX packet to be 576 bytes. The pad
data will contain a repeating sequence of zero's through 0xFF's.
should stop compression modems from collapsing the packet
destroying the link delay calculation
Currently Assigned WOption Numbers (Timer Request Packet):
Routing Type Option = 0x00; Option Length = 0001
Current option data values
0 Novell RIP/SAP routing with
number assigned to the link
PAD Type Option = 0xFF; Option Length =
Compression Option = 0x80; Option Length =
(length dependent on compression type
Current option data values
Byte 1 Compression
0 = Telebit compression (length=3) [6]
Telebit Byte 2 - Compression
Telebit Byte 3 - Number compression
Allen [Page 7]
RFC 1362 IPXWAN September 1992
4.2. Timer Response
+---------------------------------------------------------------+
| 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 | 02 | 2 Options follow |
| 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 |
| | | (Minimum interoperating
| | | requirement). Others |
| | | may be defined by at a |
| | | later date by Novell |
| WOption Number | FF | Pad option |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic
| WOption Data Len | 02 0E | Pad data length (Hi Lo)|
| WOption Data | 00->FF's | Repeated sequence of 00|
| | | through FF's to stop |
| | | compression modems |
| | | doing any compression |
| | | for link delay calc. |
+---------------------------------------------------------------+
The responses contained within this packet are as described
section 4.1. Any unknown options or not supported options from
Timer Request should have the WAccept Option set to NO
If the Timer Request packet contained more than one Router
option and the "Slave" supports all the options, the "Slave"
set the WAccept Option to NO on all Router Types except the
Allen [Page 8]
RFC 1362 IPXWAN September 1992
Type which is to be adopted. The "Master" of the link will then
the routing option specified with the YES setting and
further information exchanges according to that routing standard
This packet should contain the same sequence number as the
Timer Request. This packet should ONLY be sent by the
determining themselves to be the "Slave" of the link
Currently Assigned WOption Numbers (Timer Response Packet):
Routing Type Option = 0x00; Option Length = 0001
Current option data values
0 Novell RIP/SAP routing with
number assigned to the link
PAD Type Option = 0xFF; Option Length =
Compression Option = 0x80; Option Length =
(length dependant on compression type
Current option data values
Byte 1 Compression
0 = Telebit compression (length=3) [6]
Telebit Byte 2 - Compression
Telebit Byte 3 - Number compression
Allen [Page 9]
RFC 1362 IPXWAN September 1992
4.3. RIP/SAP Information Request Packet (Router Type=0 Only
+---------------------------------------------------------------+
| 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. |
+---------------------------------------------------------------+
Allen [Page 10]
RFC 1362 IPXWAN September 1992
Calculation of link delay is performed as follows
// Start_time is a time stamp when Timer Request sent
// End_time is a time stamp when a Timer Response
// received
link_delay = end_time - start_time; // 1/18th
// We are on a slow net, so add some biasing to help
// multiple workstation sessions timing out on the
if (link_delay < 1)
{
link_delay = 1;
}/*IF*/
link_delay *= 6; // Add the
link_delay *= 55; // Convert link delay to
The "Link Delay" is used as the network transport time
advertized in the IPX RIP packet tuple for the network entry "
Net #". For a consistent network, a common link delay is required
both ends of the link and is calculated by the link "Master".
The Common Net # is supplied by the link "Master". This number
be unique in the connected internetwork. Each WAN call requires
separate number
Currently only a single option is defined for the "
Request" packet for Routing Type=0.
Allen [Page 11]
RFC 1362 IPXWAN September 1992
4.4. RIP/SAP Information Response Packet (Router Type=0 Only
+---------------------------------------------------------------+
| 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 | 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 (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
section 4.3.
5.
[1] Simpson, W., "The Point-to-Point Protocol (PPP) for
Transmission of Multi-protocol Datagrams over Point-to-
Links", RFC 1331, May 1992.
[2] Malis, A., Robinson, D., and R. Ullman, "
Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356,
August 1992.
Allen [Page 12]
RFC 1362 IPXWAN September 1992
[3] Bradley, T., Brown, C., and A. Malis, "Multiprotocol
over Frame Relay", RFC 1294, January 1992.
[4] Simpson, W., "The PPP Internetwork Packet Exchange
Protocol (IPXCP) Compromise Version", Work in Progress
[5] Novell IPX Router Specification. Novell Part Number 107-000029-
001. (Note: Currently, this document is only available as
of a Novell developers program as part of an SDK. Novell Labs
Provo (UT) should be able to provide more information on
document.)
[6] Lewis, M., Telebit Corp. "IPX Header Compression based on
Jacobson Header Compression for TCP/IP", Work in Progress
contact: (mlewis@telebit.com).
6. Security
Security issues are not discussed in this memo
7. Author's
Michael
Novell, Inc
2180 Fortune
San Jose, CA 95131
EMail: MALLEN@NOVELL.
Chair's Address
The working group can be contacted via the current chair
Brian
Lloyd &
3420 Sudbury
Cameron Park, California 95682
EMail: brian@ray.lloyd.
Phone: (916) 676-1147
Allen [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
