📄 rfc1634.txt
字号:
Network Working Group M. Allen
Request For Comments: 1634 Novell, Inc.
Obsoletes: 1551, 1362 May 1994
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 RFC 1551. The
changes from RFC 1551 are to correct a problem in the wording when an
RFC 1362 router talks to an RFC 1551 router and to allow numbers to
be specified in a Router Name.
Table of Contents
1. Introduction ................................................. 2
1.1 Operation Over PPP ........................................... 2
1.2 Operation Over X.25 Switched Virtual Circuits ................ 2
1.3 Operation Over X.25 Permanent Virtual Circuits ............... 3
1.4 Operation Over Frame Relay ................................... 3
1.5 Operation Over Other WAN Media ............................... 3
2. Glossary Of Terms ............................................ 4
3. IPX WAN Protocol Description ................................. 4
3.1 The Initial Negotiation ...................................... 5
3.2 Information Exchange ......................................... 9
3.3 NAK Packets .................................................. 10
4. Information Exchange Packet Formats .......................... 10
4.1 Timer Request Packet ......................................... 12
4.2 Timer Response Packet ........................................ 15
4.3 Information Request Packet ................................... 16
4.4 Information Response Packet .................................. 19
5. Running Unnumbered RIP ....................................... 20
6. Workstation Connectivity ..................................... 20
7. On-demand, Statically Routed Links ........................... 20
8. References ................................................... 22
9. Security Considerations ...................................... 22
10. Author's Address.............................................. 23
Allen [Page 1]
RFC 1634 IPXWAN May 1994
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 1634 IPXWAN May 1994
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 1634 IPXWAN May 1994
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', '0' through '9', 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 1634 IPXWAN May 1994
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 1634 IPXWAN May 1994
- 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) IPX 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 for 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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -