📄 rfc1552.txt
字号:
RFC 1552 PPP IPXCP December 1993
indicate with a zero value that the peer provide the information.
By default, no node number is assigned to the link (the node
number is zero). There is no need for a node number if the
interface is not used by a routing protocol.
This is a Desired Parameter when the implementation is operating
as an end-system. However, when the node number has been
statically configured, this option SHOULD NOT be negotiated unless
requested by the peer.
Any IPX-WAN packets received MUST supercede information negotiated
in this option.
A summary of the IPX-Node-Number Configuration Option format is
shown below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPX-Node-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPX-Node-Number (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
2
Length
8
IPX-Node-Number
The six octet IPX-Node-Number is the desired local IPX node number
of the sender of the Configure-Request.
3.3 IPX-Compression-Protocol
Description
This Configuration Option provides a way to negotiate the use of a
specific compression protocol. By default, compression is not
enabled.
The sender of this Configuration Option indicates that it can
receive packets with the specified compression technique. A
Simpson [Page 9]
RFC 1552 PPP IPXCP December 1993
Configure-Ack MAY obligate the peer to send such packets,
depending on the protocol negotiated.
Information negotiated in this option MUST supercede any IPX-WAN
packets received, since IPX-WAN packets could be affected by the
compression technique.
A summary of the IPX-Compression-Protocol Configuration Option
format is shown below. The fields are transmitted from left to
right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPX-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Type
3
Length
>= 4
IPX-Compression-Protocol
The IPX-Compression-Protocol field is two octets and indicates the
compression protocol desired. Odd values for this field are always
the same as the PPP Data Link Layer Protocol field values for that
same compression protocol. Even values are used when the compression
protocol is interleaved with IPX packets.
Up-to-date values of the IPX-Compression-Protocol field are specified
in the most recent "Assigned Numbers" RFC [2]. Current values are
assigned as follows:
Value (in hex) Protocol
0002 Telebit Compressed IPX
0235 Shiva Compressed NCP/IPX
Data
The Data field is zero or more octets and contains additional data
as determined by the particular compression protocol.
Simpson [Page 10]
RFC 1552 PPP IPXCP December 1993
3.4 IPX-Routing-Protocol
Description
This Configuration Option provides a way to negotiate the use of a
specific routing protocol (or no routing protocol, if desired).
The sender of this option is specifying that it wishes to receive
information of the specified routing protocol. Multiple protocols
MAY be requested by sending multiple IPX-Routing-Protocol
Configuration Options. The "no routing protocol required" value
is mutually exclusive with other values.
By default, Novell's combination of Routing Information Protocol
(RIP) and Server Advertising Protocol (SAP) is expected.
This is a Desired Parameter when the implementation is operating
as an end-system, to indicate that no routing protocol is
necessary.
Any IPX-WAN packets received MAY add to information negotiated in
this option.
A summary of the IPX-Routing-Protocol Configuration Option format is
shown below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPX-Routing-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Type
4
Length
>= 4
IPX-Routing-Protocol
The IPX-Routing-Protocol field is two octets and indicates the
type of Routing-Protocol desired. This two octet quantity is sent
most significant octet first.
Up-to-date values of the IPX-Routing-Protocol field are specified
Simpson [Page 11]
RFC 1552 PPP IPXCP December 1993
in the most recent "Assigned Numbers" RFC [2]. Current values are
assigned as follows:
Value Protocol
0 No routing protocol required
1 RESERVED
2 Novell RIP/SAP required
4 Novell NLSP required
Data
The Data field is zero or more octets and contains additional data
as determined by the routing protocol indicated in the Routing-
Protocol field.
3.5 IPX-Router-Name
Description
This Configuration Option provides a way to convey information
about the IPX server name.
The nature of this option is advisory only. It is provided as a
means of improving the end system's ability to provide a simple
user interface. This option MUST NOT be included in a Configure-
Nak.
A summary of the IPX-Router-Name Option format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Name... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
5
Length
>= 3
Simpson [Page 12]
RFC 1552 PPP IPXCP December 1993
Name
This field contains the name of the IPX entity on this end of the
link. The symbolic name should be between 1 and 47 ASCII
characters in length, containing the characters 'A' through 'Z',
underscore (_), hyphen (-) and "at" sign (@). The length of the
name is bounded by the option length.
On reception, the name SHOULD be padded to 48 characters using the
NUL character. Those readers familiar with NetWare 3.x servers
will realize that this is equivalent to the file server name.
3.6 IPX-Configuration-Complete
Description
This Configuration Option provides a way to indicate that all
implementation-dependent Desired Parameters are satisfied. It is
provided as a means of detecting when convergence will occur in a
heterogeneous environment.
This option SHOULD be included in a Configure-Request when the
combination of statically configured parameters and offered
Configuration Options will result in successful configuration.
The nature of this option is advisory only. This option MUST NOT
be included in a Configure-Nak.
Implementation Note: An implementation which does not support
IPX-WAN can immediately detect that link setup will not be
successful when a Desired Parameter is unknown, if this option is
not present in the peer's Configure-Request or is Rejected by the
peer. This avoids timeout delays.
An implementation which supports IPX-WAN may improve link setup
time by skipping IPX-WAN entirely when this option has been Ack'd
in both directions.
However, it is perfectly acceptable to complete configuration
without including this option. An implementation which includes
the entire panoply of configuration options and IPX- WAN SHOULD
interoperate with an implementation which does not support IPX-WAN
nor any configuration options (including this one), as long as the
Desired Parameters are satisfied by default or hand configuration.
A summary of the IPX-Configuration-Complete Option format is shown
below. The fields are transmitted from left to right.
Simpson [Page 13]
RFC 1552 PPP IPXCP December 1993
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
6
Length
2
APPENDIX A. Link Delay and Throughput
There has been some concern over correctly estimating the link delay
(in 55 millisecond ticks) used by Novell routing protocols.
IPX-WAN uses its Timer Request and Reply for this purpose. The
measured delay is multiplied by a factor of 6, because the
measurement is done during initialization of the link, and does not
reflect actual loading.
The delay is better measured using the PPP LCP Echo facility, by
inserting a timestamp in the data part of the Request, and comparing
it with the same timer when the reply returns. This method could be
used to periodically re-evaluate the actual round trip delay as link
and system loads change. The echo packet size SHOULD be 576, to
match the default IPX packet size.
In the absence of such dynamic measurements, empirical evidence has
shown the following to be sufficient:
2,400 bps 134 ticks
14,400 bps 21 ticks
57,600 bps 5 ticks
> 1 Mbps 1 tick
Security Considerations
Security issues are not discussed in this memo.
Simpson [Page 14]
RFC 1552 PPP IPXCP December 1993
References
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1548,
Daydreamer, December 1993.
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[3] Novell Inc., "NetWare System Interface Technical Overview",
Novell Part Number 883-001143-001.
[4] Allen, M., "Novell IPX Over Various WAN Media", RFC 1551,
Novell Inc., December 1993.
[5] Mathu, S., and M. Lewis, "Compressing IPX Headers Over WAN
Media (CIPX)", RFC 1553, Telebit Corporation, December 1993.
Acknowledgments
Some of the text in this document is taken from previous documents
produced by the Point-to-Point Protocol Working Group of the Internet
Engineering Task Force (IETF).
This document is derivative of drafts written by the following
people. Many thanks for their work, and for taking an initial stab
at the protocol:
Michael Allen (mallen@novell.com)
Dave McCool (dave@shiva.com)
Robert D Vincent (bert@shiva.com)
Marty Del Vecchio (marty@shiva.com)
Chair's Address
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
Simpson [Page 15]
RFC 1552 PPP IPXCP December 1993
Author's Address
Questions about this memo can also be directed to:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
P O Box 6205
East Lansing, MI 48826-6205
EMail: Bill.Simpson@um.cc.umich.edu
Simpson [Page 16]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -