As per Relevance of the word parameter, we have this rfc below:
Network Working Group W.
Request for Comments: 1552
Category: Standards Track December 1993
The PPP Internetwork Packet Exchange Control Protocol (IPXCP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
The Point-to-Point Protocol (PPP) [1] provides a method
transmitting multi-protocol datagrams over point-to-point links.
defines an extensible Link Control Protocol, and proposes a family
Network Control Protocols for establishing and configuring
network-layer protocols
The IPX protocol was originally used in Novell's NetWare
[3], and is now supported by numerous other vendors. This
defines the Network Control Protocol for establishing and
the IPX protocol over PPP
This memo is the product of the Point-to-Point Protocol Working
of the IETF. Comments should be submitted to the ietf
ppp@ucdavis.edu mailing list
Simpson [Page 1]
RFC 1552 PPP IPXCP December 1993
Table of
1. Introduction ...................................................2
1.1 Specification of Requirements ..................................3
1.2 Terminology ....................................................3
2. A PPP Network Control Protocol for IPX .........................4
2.1 Sending IPX Datagrams ..........................................5
2.2 IPX-WAN protocol ...............................................5
2.3 Desired Parameters .............................................5
2.4 Co-existence with IPX-WAN ......................................6
3. IPXCP Configuration Options ....................................6
3.1 IPX-Network-Number .............................................7
3.2 IPX-Node-Number ................................................8
3.3 IPX-Compression-Protocol .......................................9
3.4 IPX-Routing-Protocol ...........................................11
3.5 IPX-Router-Name ................................................12
3.6 IPX-Configuration-Complete .....................................13
APPENDIX A. Link Delay and Throughput ..............................14
SECURITY CONSIDERATIONS ............................................14
REFERENCES .........................................................15
ACKNOWLEDGEMENTS ...................................................15
CHAIR'S ADDRESS ....................................................15
AUTHOR'S ADDRESS ...................................................16
1.
PPP has three main components
1. A method for encapsulating multi-protocol datagrams
2. A Link Control Protocol (LCP) for establishing, configuring
and testing the data-link connection
3. A family of Network Control Protocols for establishing
configuring different network-layer protocols
In order to establish communications over a point-to-point link,
end of the PPP link must first send LCP packets to configure and
the data link. After the link has been established and
facilities have been negotiated as needed by the LCP, PPP must
IPXCP packets to choose and configure the IPX network-layer protocol
Once IPXCP has reached the Opened state, IPX datagrams can be
over the link
The link will remain configured for communications until explicit
or IPXCP packets close the link down, or until some external
occurs (an inactivity timer expires or network
intervention).
Simpson [Page 2]
RFC 1552 PPP IPXCP December 1993
1.1 Specification of
In this document, several words are used to signify the
of the specification. These words are often capitalized
This word, or the adjective "required", means that the
is an absolute requirement of the specification
MUST
This phrase means that the definition is an absolute
of the specification
This word, or the adjective "recommended", means that there
exist valid reasons in particular circumstances to ignore
item, but the full implications should be understood and
weighed before choosing a different course
This word, or the adjective "optional", means that this item
one of an allowed set of alternatives. An implementation
does not include this option MUST be prepared to interoperate
another implementation which does include the option
1.2
This document frequently uses the following terms
The other end of the point-to-point link
silently
This means the implementation discards the packet without
processing. The implementation SHOULD provide the capability
logging the error, including the contents of the
discarded packet, and SHOULD record the event in a
counter
Simpson [Page 3]
RFC 1552 PPP IPXCP December 1993
end-
A user's machine. It only sends packets to servers and
end-systems. It doesn't pass any packets through itself
Allows packets to pass through, usually from one ethernet
to another. Sometimes these are called "intermediate-systems".
half-
Two normal routers, with an unnumbered link between them.
looks like a router to the local users, but Netware doesn'
understand unnumbered links, so each router is made to look
they both are a single machine
2. A PPP Network Control Protocol for
The IPX Control Protocol (IPXCP) is responsible for configuring
enabling, and disabling the IPX protocol modules on both ends of
point-to-point link. IPXCP uses the same packet exchange
as the Link Control Protocol. IPXCP packets may not be
until PPP has reached the Network-Layer Protocol phase.
packets received before this phase is reached should be
discarded
The IPX Control Protocol is exactly the same as the Link
Protocol [1] with the following exceptions
Frame
The packet may utilize any modifications to the basic frame
which have been negotiated during the Link Establishment phase
Data Link Layer Protocol
Exactly one IPXCP packet is encapsulated in the Information
of a PPP Data Link Layer frame where the Protocol field
type hex 802B (IPX Control Protocol).
Code
Only Codes 1 through 7 (Configure-Request, Configure-Ack
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-
and Code-Reject) are used. Other Codes should be treated
unrecognized and should result in Code-Rejects
Simpson [Page 4]
RFC 1552 PPP IPXCP December 1993
IPXCP packets may not be exchanged until PPP has reached
Network-Layer Protocol phase. An implementation should
prepared to wait for Authentication and Link Quality
to finish before timing out waiting for a Configure-Ack or
response. It is suggested that an implementation give up
after user intervention or a configurable amount of time
Configuration Option
IPXCP has a distinct set of Configuration Options
2.1 Sending IPX
Before any IPX packets may be communicated, PPP must reach
Network-Layer Protocol phase, and the IPX Control Protocol must
the Opened state
Exactly one IPX packet is encapsulated in the Information field of
PPP Data Link Layer frame where the Protocol field indicates type
002B (IPX datagram).
The maximum length of an IPX datagram transmitted over a PPP link
the same as the maximum length of the Information field of a PPP
link layer frame. Since there is no standard method for
and reassembling IPX datagrams, PPP links supporting IPX MUST
at least 576 octets in the information field of a data link
frame
2.2 IPX-WAN
A Novell specification called IPX-WAN [4] is intended to
mechanisms similar to IPXCP negotiation over wide area links.
viewed by PPP, IPX-WAN is a part of IPX, and IPX-WAN packets
indistinguishable from other IPX packets
Currently, Novell has implemented IPXCP without any
Options, and requires successful IPX-WAN completion, even when
required parameters have been hand configured. This makes
impossible for the current Novell products to interoperate with
IPXCP implementations which do not already include support for IPX
WAN
2.3 Desired
To resolve the possible conflict between the two
methods, this specification defines the concept of "
Simpson [Page 5]
RFC 1552 PPP IPXCP December 1993
Parameters". Where applicable, each Configuration Option
the environment where the parameter which is negotiated MAY
required by the implementation for proper operation
This determination is highly implementation dependent. For example
a particular implementation might require that all links
addresses, while another implementation might not need
addresses. The configuration negotiation is intended to
that this pair of implementations will never converge
2.4 Co-existence with IPX-
An IPXCP implementation which includes support for IPX-WAN
always reach Opened state, even when unable to negotiate
"Desired Parameter", and when no Configuration Options
successfully negotiated. This allows IPX-WAN the opportunity
finish the negotiation
If an implementation does not include support for IPX-WAN, it
NOT reach Opened state when unable to negotiate some "
Parameter".
IPX-WAN uses a "Timer Request" packet to set up the link. These
NOT be sent until IPXCP has Opened the link
An implementation which provides both IPX-WAN and IPXCP
Options capability SHOULD only send a Timer Request packet when
Timer Request packet is received, or upon failure to
negotiate a "Desired Parameter".
If unable to complete IPX-WAN setup when a "Desired Parameter"
unknown, by default IPXCP SHOULD terminate the link
However, some implementations might be capable of operating
all indicated "Desired Parameters", in which case the
MUST be configurable
3. IPXCP Configuration
IPXCP Configuration Options allow modifications to the
characteristics of the network-layer protocol to be negotiated. If
Configuration Option is not included in a Configure-Request packet
the default value for that Configuration Option is assumed
IPXCP uses the same Configuration Option format defined for LCP [1],
with a separate set of Options
Up-to-date values of the IPXCP Option Type field are specified in
Simpson [Page 6]
RFC 1552 PPP IPXCP December 1993
most recent "Assigned Numbers" RFC [2]. Current values are
as follows
1 IPX-Network-
2 IPX-Node-
3 IPX-Compression-
4 IPX-Routing-
5 IPX-Router-
6 IPX-Configuration-
3.1 IPX-Network-
This Configuration Option provides a way to negotiate the
network number to be used for the link. This allows
implementation to learn the network number, or to ensure
on the network number
The network number MUST be unique within the routing domain,
zero to indicate that it is not used for routing
The sender of the Configure-Request states which network number
desired. A network number specified as zero in a Configure
Request shall be interpreted as requesting the peer to
another value in a Configure-Nak. A network number specified
zero in a Configure-Ack shall be interpreted as agreement that
value exists
Both ends of the link MUST have the same network number. When
Configure-Request is received which has a lower network
than locally configured, a Configure-Nak MUST be returned with
highest network number
When the peer did not provide the option in its Configure-Request
the option SHOULD NOT be appended to a Configure-Nak
By default, no network number is assigned to the link (the
number is zero). There is no need for a network number if
interface is not used by a routing protocol
This is a Desired Parameter when the implementation is
as a router. It MUST be negotiated if the network number is non
zero, and has been derived from another interface
Any IPX-WAN packets received MUST supercede information
in this option
Simpson [Page 7]
RFC 1552 PPP IPXCP December 1993
A summary of the IPX-Network-Number Configuration Option format
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-Network-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPX-Network-Number (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
6
IPX-Network-
The four octet IPX-Network-Number is the desired local IPX
number of the sender of the Configure-Request. This number may
zero, which is interpreted as being a local network of
number that is not used by the routing protocol
3.2 IPX-Node-
This Configuration Option provides a way to negotiate the IPX
number to be used for the local end of the link. This allows
implementation to learn its node number, or to inform the peer
its node number
The node number MUST be unique for the network number
The sender of the Configure-Request states which node number
desired. A node number specified as zero in a Configure-
shall be interpreted as requesting the peer to specify
value in a Configure-Nak. A node number specified as zero in
Configure-Ack shall be interpreted as agreement that no
exists
If negotiation about the peer node number is required, and
peer did not provide the option in its Configure-Request,
option can be appended to a Configure-Nak. The value of the
number given MUST be acceptable as the peer IPX-Node-Number,
Simpson [Page 8]
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
number is zero). There is no need for a node number if
interface is not used by a routing protocol
This is a Desired Parameter when the implementation is
as an end-system. However, when the node number has
statically configured, this option SHOULD NOT be negotiated
requested by the peer
Any IPX-WAN packets received MUST supercede information
in this option
A summary of the IPX-Node-Number Configuration Option format
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.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2
8
IPX-Node-
The six octet IPX-Node-Number is the desired local IPX node
of the sender of the Configure-Request
3.3 IPX-Compression-
This Configuration Option provides a way to negotiate the use of
specific compression protocol. By default, compression is
enabled
The sender of this Configuration Option indicates that it
receive packets with the specified compression technique.
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-
packets received, since IPX-WAN packets could be affected by
compression technique
A summary of the IPX-Compression-Protocol Configuration
format is shown below. The fields are transmitted from left
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 ...
+-+-+-+-+
3
>= 4
IPX-Compression-
The IPX-Compression-Protocol field is two octets and indicates
compression protocol desired. Odd values for this field are
the same as the PPP Data Link Layer Protocol field values for
same compression protocol. Even values are used when the
protocol is interleaved with IPX packets
Up-to-date values of the IPX-Compression-Protocol field are
in the most recent "Assigned Numbers" RFC [2]. Current values
assigned as follows
Value (in hex)
0002 Telebit Compressed
0235 Shiva Compressed NCP/
The Data field is zero or more octets and contains additional
as determined by the particular compression protocol
Simpson [Page 10]
RFC 1552 PPP IPXCP December 1993
3.4 IPX-Routing-
This Configuration Option provides a way to negotiate the use of
specific routing protocol (or no routing protocol, if desired).
The sender of this option is specifying that it wishes to
information of the specified routing protocol. Multiple
MAY be requested by sending multiple IPX-Routing-
Configuration Options. The "no routing protocol required"
is mutually exclusive with other values
By default, Novell's combination of Routing Information
(RIP) and Server Advertising Protocol (SAP) is expected
This is a Desired Parameter when the implementation is
as an end-system, to indicate that no routing protocol
necessary
Any IPX-WAN packets received MAY add to information negotiated
this option
A summary of the IPX-Routing-Protocol Configuration Option format
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 ...
+-+-+-+-+
4
>= 4
IPX-Routing-
The IPX-Routing-Protocol field is two octets and indicates
type of Routing-Protocol desired. This two octet quantity is
most significant octet first
Up-to-date values of the IPX-Routing-Protocol field are
Simpson [Page 11]
RFC 1552 PPP IPXCP December 1993
in the most recent "Assigned Numbers" RFC [2]. Current values
assigned as follows
Value
0 No routing protocol
1
2 Novell RIP/SAP
4 Novell NLSP
The Data field is zero or more octets and contains additional
as determined by the routing protocol indicated in the Routing
Protocol field
3.5 IPX-Router-
This Configuration Option provides a way to convey
about the IPX server name
The nature of this option is advisory only. It is provided as
means of improving the end system's ability to provide a
user interface. This option MUST NOT be included in a Configure
Nak
A summary of the IPX-Router-Name Option format is shown below.
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5
>= 3
Simpson [Page 12]
RFC 1552 PPP IPXCP December 1993
This field contains the name of the IPX entity on this end of
link. The symbolic name should be between 1 and 47
characters in length, containing the characters 'A' through 'Z',
underscore (_), hyphen (-) and "at" sign (@). The length of
name is bounded by the option length
On reception, the name SHOULD be padded to 48 characters using
NUL character. Those readers familiar with NetWare 3.x
will realize that this is equivalent to the file server name
3.6 IPX-Configuration-
This Configuration Option provides a way to indicate that
implementation-dependent Desired Parameters are satisfied. It
provided as a means of detecting when convergence will occur in
heterogeneous environment
This option SHOULD be included in a Configure-Request when
combination of statically configured parameters and
Configuration Options will result in successful configuration
The nature of this option is advisory only. This option MUST
be included in a Configure-Nak
Implementation Note: An implementation which does not
IPX-WAN can immediately detect that link setup will not
successful when a Desired Parameter is unknown, if this option
not present in the peer's Configure-Request or is Rejected by
peer. This avoids timeout delays
An implementation which supports IPX-WAN may improve link
time by skipping IPX-WAN entirely when this option has been Ack'
in both directions
However, it is perfectly acceptable to complete
without including this option. An implementation which
the entire panoply of configuration options and IPX- WAN
interoperate with an implementation which does not support IPX-
nor any configuration options (including this one), as long as
Desired Parameters are satisfied by default or hand configuration
A summary of the IPX-Configuration-Complete Option format is
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6
2
APPENDIX A. Link Delay and
There has been some concern over correctly estimating the link
(in 55 millisecond ticks) used by Novell routing protocols
IPX-WAN uses its Timer Request and Reply for this purpose.
measured delay is multiplied by a factor of 6, because
measurement is done during initialization of the link, and does
reflect actual loading
The delay is better measured using the PPP LCP Echo facility,
inserting a timestamp in the data part of the Request, and
it with the same timer when the reply returns. This method could
used to periodically re-evaluate the actual round trip delay as
and system loads change. The echo packet size SHOULD be 576,
match the default IPX packet size
In the absence of such dynamic measurements, empirical evidence
shown the following to be sufficient
2,400 bps 134
14,400 bps 21
57,600 bps 5
> 1 Mbps 1
Security
Security issues are not discussed in this memo
Simpson [Page 14]
RFC 1552 PPP IPXCP December 1993
[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
Media (CIPX)", RFC 1553, Telebit Corporation, December 1993.
Some of the text in this document is taken from previous
produced by the Point-to-Point Protocol Working Group of the
Engineering Task Force (IETF).
This document is derivative of drafts written by the
people. Many thanks for their work, and for taking an initial
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
The working group can be contacted via the current chair
Fred
Advanced Computer
315 Bollay
Santa Barbara, California, 93111
EMail: fbaker@acc.
Simpson [Page 15]
RFC 1552 PPP IPXCP December 1993
Author's
Questions about this memo can also be directed to
William Allen
Computer Systems Consulting
P O Box 6205
East Lansing, MI 48826-6205
EMail: Bill.Simpson@um.cc.umich.
Simpson [Page 16]
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
