RFC relevance of appendix

As per Relevance of the word appendix, we have this rfc below:

Network Working Group T.
Request for Comments: 1791 Novell, Inc
Category: Experimental April 1995

TCP And UDP Over IPX Networks With Fixed Path

Status of this

This document defines an Experimental Protocol for the
community. This does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited

IESG Note

Internet Engineering Steering Group comment from the Area
for Transport Services: Please note well that this memo is
individual product of the author. Implementation experience
particularly on the effectiveness of the protocols in dual-
environments, is needed

1.

Most of network applications run on some sort of transports. And,
one is to let such applications to run over a foreign
protocol, the simplest way would be to allow the applications
transports to run over that network protocol. For TCP/
applications, that transport is TCP or UDP. Hence, to let TCP/
applications run over IPX, we would need to have TCP and UDP
over IPX. And, once TCP and UDP are allowed to run over IPX, all
and UDP based applications, such as HTTP for WWW, or NFS, can
be made to work over IPX networks

DLsw is another example of such applications. As it is a
application (and TCP requires IP), the administrator is forced to
IP on his network in order to support DLsw. If the site was an
shop, it means that he now must manage IP protocol/addresses
addition to IPX. If TCP could be made to run on IPX, then he
not have to add IP to his repertoire of network protocols to manage

TCP/IPX allows TCP/IP applications to run over IPX networks
letting TCP and UDP run over IPX. And this memo specifies the
format and operational procedures for running TCP and UDP over IPX

Sung [Page 1]

RFC 1791 TCP And UDP Over IPX April 1995

2. Running UDP Over

Since UDP datagrams can be up to 64K octets long, and the size of
packet is limited to that of the path MTU, large UDP datagrams
be fragmented. And, since IPX does not support fragmentation,
UDP datagrams must be fragmented before they are passed to IPX.
that purpose, a new protocol called IPXF (IPX Fragmentation layer),
is invented. UDP must run on IPXF rather than directly on IPX.
layer is described in section 4.

To IPXF service users, IPXF behaves just like IPX except that
accepts datagram larger than the IPX path MTU. As such, we
UDP in this section as if it is running on IPX

UDP must send and receive the packets on IPX/IPXF socket 0x9092.
Though it may be possible to send a packet from sockets other
0x9092, such sockets cannot receive UDP datagram destined to a
known socket 0x9092. Hence, the bidirectional communcation may
be established if a socket other than 0x9092 is used to send
datagram. For that reason. UDP/IPX does not allow source
other than 0x9092. If a datagram with source socket number
than 0x9092 is received, UDP/IPX should discard the packet silently
(And increment udpInDatagramErr MIB counter if it is instrumented.)

UDP over IPX uses the IPX packet type 4, a normal IPX packet type
The IPX packet type has no meaning to TCP/IPX protocol. It simply
a number required by IPX for general IPX packets

See Appendix B.1 and B.2 for UDP over IPX packet format

The UDP/IPX checksum uses a pseudo header similar to UDP/IP
header. The only difference is that IP addresses and protocol ID
replaced by IPX addresses and socket numbers

See Appendix B.3 for the UDP/IPX pseudo header format

3. Running TCP Over

Unlike UDP, TCP runs directly over IPX. Since IPX does not
fragmentation, no TCP segment sent over IPX can be larger than
path MTU for the connection. The discovery of the path MTU
outside of scope of this paper. If the implementation does not
a way to dynamically determine the path MTU for each connection,
should at least allow a way to statically configure a
value for all connections. For example, if the internetwork made
ethernets only, the user may configure the segment size to be 1470
including the TCP header. If the configuration of the segment
is not possible, the implementation should assume that the IPX

Sung [Page 2]

RFC 1791 TCP And UDP Over IPX April 1995

MTU is 576 octects, and not send any TCP segment larger than 546
octets including TCP header. That will result in IPX packet of 576
octets which is the minimum path MTU for IPX. The implementation
then advised to comunicate the configured/default segment size to
peer TCP by exchanging MSS option

Note that this memo does not preclude the possibility of running
over IPXF instead of IPX. Running on IPXF can be done in the
manner as running UDP over IPXF. However, in general, TCP
refrain from sending large segments that may result in fragmentation
Hence, running TCP over IPXF is not recommended

The IPX socket number 0x9091 is reserved for the TCP. All TCP
must be sent from and received on the socket 0x9091. If the
TCP/IPX packet has the source IPX socket number other than 0x9091,
the packet should be discarded silently. (And increment tcpInErrs
counter if it is instrumented.)

TCP, like UDP, uses IPX packet type 4. The IPX packet type has
meaning to TCP/IPX protocol. It is packet type required by IPX
general IPX packets

See appendix A.1 for TCP/IPX packet format

The TCP pseudo header, used in checksuming for TCP over IPX,
similar to TCP pseudo header for TCP over IP. Again, the
is that IPX addresses and IPX socket number are substituted in
of IP addresses and IP protocol number

See Appendix A.2 for the TCP/IPX pseudo header format

4. IPXF

A large UDP datagram cannot be sent directly over IPX as IPX does
support datagrams larger than the path MTU. Hence, large
datagrams must be fragmented before it can be sent over IPX. To
large UDP datagrams fragmented, UDP runs over IPXF layer instead
running directly IPX

IPXF users treats IPXF as if it is IPX layer. That is, they
datagrams to IPXF specifying the destination IPX address/socket
with the packet. They also must set the source socket number of
datagram to its actual IPX socket number, as it would when
packets to IPX layer. (For UDP, both source and destination
are 0x9092.)

Datagrams passed to IPXF can be upto 64K octets long

Sung [Page 3]

RFC 1791 TCP And UDP Over IPX April 1995

IPXF fragments a datagram as necessary, prepends each fragment
the IPXF header and send them to the IPX socket 0x9093 in
destination IPX address. The actual destination socket
(0x9092 for UDP) in the orignal IPX datagram is preserved in
header. Refer to Appendix B.2 for UDP/IPXF/IPX packet format

The largest possible IPX datagram that can be sent over the IPX
is limited by the path MTU size. The mechanism to discover the
MTU is outside of the scope of the paper. If an IPXF
does not have a mean to determine the path MTU, it should assume
the largest IPX packet size is 576. In that case, any UDP
larger than 546 octects will have to be fragmented

If the datagram does not require fragmentation, IPXF acts as a
layer. That is, the whole packet is directly sent to the actual
destination socket without the IPXF fragmentation header. Refer
Appendix B.1 for UDP/IPX packet format without the IPXF header

An IPXF user receives datagrams by opening a socket with IPXF just
it would with IPX. For example, UDP opens the socket 0x9092
IPXF to receive UDP datagrams. IPXF, in turn, opens IPX socket
the same number with IPX, so that unfragmented packets directed
that socket will be delivered by IPX directly to the IPXF user

IPXF fragments are received by IPXF on the IPX socket 0x9093.
receiving IPXF then reassembles the fragments into a complete
datagram, restores the actual detination IPX socket number from
IPXF header and delivers the reassembled IPX datagram to its
recipient designated by the restored socket number

Upon receiving a fragment, IPXF must ignore the source socket
in the IPX header of the fragment. The source IPX socket field
IPX header contains the actual source of the IPX datagram. As such
the source IPX socket number in IPX header usually is not 0x9093,
it is meaningful only to the actual recepient of the
datagram

The fragmentation/reassembly algorithm used by IPXF is identical
that of IP, except for the following exceptions: 1) the offset
fragments are measured in units of octets rather than in units of 8
octets. 2) if the receiving IPXF does not have sufficient
for the reassembly, it should discard fragments immediately.
receiving IPXF can determine if it has sufficient resources
looking at the length of the original datagram included in
fragment

Note that, though it is required only for UDP in this memo, IPXF
also be used by any protocol that requires IPX fragmentation support

Sung [Page 4]

RFC 1791 TCP And UDP Over IPX April 1995

5. TCP/IPX

TCP/IPX is checksummed in exactly same manner as TCP/IP. It uses 16
bit 1's complement of 1's compliment sum of all 16 bit words in
pseudo header and text. See Appendix A.2 and B.3 for the
header format for TCP and UDP

6.

TCP and UDP data over IPX are delivered to the application in
same manner as in TCP/IP. That is, they are delivered to the
specific matching endpoint, with the match made on local port,
port, local IPX address and remote IPX address

When TCP or UDP is running over both IPX and IP, the
endpoint also identifies the network layer on which the endpoint is
Hence, the triplet of network address, network address family,
the port number forms the socket. And, the endpoint match must
made on the the network address familty as well

For exmple, an endpoint bound to IPX network layer would
identified by AF_IPX, IPX address and TCP port number. On the
hand, endpoints bound to IP network layer would be identified
AF_IP, IP address, and TCP port. Finally, endpoints not bound to
network layer would be identified by AF_UNSPEC and TCP port

First, an attempt is made to deliver the data to the most
endpoint that is bound to the network layer that the packet
from. If there is no such endpoint, then the packet is delivered
the best matching endpoint that is not bound to any network layer
all. For example, if the packet arrived over IPX network, then
packet is delivered to the most specific matching endpoint that
bound to IPX. If there is no matching endpoint over IPX, then it
delivered to an endpoint that did not specify any network layer

The use of endpoints not bound to any network layer is similar
TCP/IP endpoints with no IP address bound to it. Such endpoints
usually used for listening for connection requests from any of
interfaces within the host. Similarly, endpoints with no
layer bound to it are used to field the connection requests from
of the network layers

The author wishes to thank following folks, in alphabetical order
and others for their helpful comments and contributions to the work
Lester Bird, Doug Kogan, Greg Minshall and Don Provan

Sung [Page 5]

RFC 1791 TCP And UDP Over IPX April 1995

Security

Security issues are not discussed in this memo

Author's

Tae
Novell, Inc
2180 Fortune
San Jose, California, 95131

Phone: (408)577-8439
EMail: tae@novell.

Sung [Page 6]

RFC 1791 TCP And UDP Over IPX April 1995

Appendix A.1 - TCP/IPX Packet

A TCP/IPX Packet has following format

+-------+-------+-------+-------+
| IPX Checksum | IPX Pkt Len |
+-------+-------+-------+-------+
| Zero |IPX PT | IPX Dest -
+-------+-------+-------+-------+
Network | IPX Dest -
+-------+-------+-------+-------+
Node |
+-------+-------+-------+-------+
| IPX Dest Skt | IPX Src -
+-------+-------+-------+-------+
Network | IPX Src -
+-------+-------+-------+-------+
Node |
+-------+-------+-------+-------+
| IPX Src Skt | TCP Header
+---------------+-------+-------+
Data...
+----...

IPX PT field contains the IPX packet type. It is set to 4
TCP/IPX packet

Both Src Skt and Dest Skt field in IPX header must be set to 0x9091
for TCP/IPX packet. If the Src Skt is not set to 0x9091,
receiving TCP/IPX should discard the packet silently. (And
tcpInErrs mib object if it is instrumented.)

Sung [Page 7]

RFC 1791 TCP And UDP Over IPX April 1995

Appendix A.2 - TCP/IPX Pseudo Header

TCP/IPX uses following pseudo header to compute checksum

+-------+-------+-------+-------+
| IPX Src Network |
+-------+-------+-------+-------+
| IPX Src
+-------+-------+-------+-------+
| IPX Src Skt |
+-------+-------+-------+-------+
| IPX Dest Network |
+-------+-------+-------+-------+
| IPX Dest
+-------+-------+-------+-------+
| IPX Dest Skt |
+-------+-------+-------+-------+
| Zero | TCP Length |
+---------------+---------------+

IPX Src/Dest Network/Node/Skt are the fields from the IPX header
TCP Length is the IPX Pkt Len minus the IPX header length in octets

Note that IPX Src Skt is expected to be 0x9091 for TCP. As such,
may insert 0x9091 in IPX Src Skt field rather than getting the
from IPX header. Then the implementation will not have to check
IPX Src Skt field in the fast path since the checksum failure
also cover the unexpected value. In that case, the
may want to examine if the checksum failure was due to the IPX
Skt value other than 0x9091, so that it can increment
counter, if proprietary counters other than tcpInErrs are used

Sung [Page 8]

RFC 1791 TCP And UDP Over IPX April 1995

Appendix B.1 - UDP/IPX Packet Format without

IPXF transmits UDP packets over IPX in this format if the
datagram does not have to be fragmented

+-------+-------+-------+-------+
| IPX Checksum | IPX Pkt Len |
+-------+-------+-------+-------+
| Zero |IPX PT | IPX Dest -
+-------+-------+-------+-------+
Network | IPX Dest -
+-------+-------+-------+-------+
Node |
+-------+-------+-------+-------+
| IPX Dest Skt | IPX Src -
+-------+-------+-------+-------+
Network | IPX Src -
+-------+-------+-------+-------+
Node |
+-------+-------+-------+-------+
| IPX Src Skt | UDP Header
+---------------+-------+-------+
Data...
+----...

The IPX PT field contains IPX packet type. It should be set to 4
all UDP/IPX packets

Both IPX Src Skt and IPX Dest Skt field must be set 0x9092.
receiving UDP/IPX should discard the packet silently if the IPX
Skt field is not set to 0x9092. (And increment udpInErrors
object if it is instrumented.)

Sung [Page 9]

RFC 1791 TCP And UDP Over IPX April 1995

Appendix B.2 - UDP/IPX Packet Format With

IPXF transmits fragmented datagrams over IPX in the following format

+-------+-------+-------+-------+
| IPX Checksum | IPX Pkt Len |
+-------+-------+-------+-------+
| Zero |IPX PT | IPX Dest -
+-------+-------+-------+-------+
Network | IPX Dest -
+-------+-------+-------+-------+
Node |
+-------+-------+-------+-------+
IPX Dest Skt | IPX Src -
+-------+-------+-------+-------+
Network | IPX Src -
+-------+-------+-------+-------+
Node |
+-------+-------+-------+-------+
| IPX Src Skt | IPXF Offset |
+---------------+-------+-------+
| IPXF Frag Identification |
+-------------------------------+
| IPXF Dest Skt | IPXF DG Len |
+-------------------------------+
| UDP Header and Data ...
+--------...

The IPX PT field contains IPX packet type. It is set to the
set by the IPXF user in the IPX packet passed to IPXF. (UDP sets
to 4.)

IPX Dest Skt field must be set to 0x9093 for all IPXF Packets

The value for IPX Src Skt field is variable, and must be set to
actual IPX socket number of the IPXF user. (For example, it must
set to 0x9092 for UDP.)

IPXF Offset field indicates where the fragment belongs in
datagram. The offset is measured is octet from the begining of
UDP datagram. The first fragment has the offset of 0.

IPXF Frag Identification field is assigned a same value by the
for all fragements belonging to the same datagram. The receiver
uses this field to reassemble all fragments with same ID into
datagram

Sung [Page 10]

RFC 1791 TCP And UDP Over IPX April 1995

IPXF Dest Skt field contains the IPX socket number of the
recipient that the reassembled datagram will be delivered to. (It
0x9092 for UDP.) All fragments of a datagram must have the
value in this field

IPXF DG Len field is the total length of the IPX datagram before
fragmentation. The sender should set it to the value of IPX Pkt
of the original IPX datagram. All fragments of a IPX datagram
have the same value in this field

Sung [Page 11]

RFC 1791 TCP And UDP Over IPX April 1995

Appendix B.3 - UDP/IPX Pseudo Header

UDP/IPX uses following pseudo header for computing the checksum

+-------+-------+-------+-------+
| IPX Src Network |
+-------+-------+-------+-------+
| IPX Src
+-------+-------+-------+-------+
| IPX Src Skt |
+-------+-------+-------+-------+
| IPX Dest Network |
+-------+-------+-------+-------+
| IPX Dest
+-------+-------+-------+-------+
| IPX Dest Skt |
+-------+-------+-------+-------+
| Zero | UDP Length |
+---------------+---------------+

IPX Src/Dest Network/Node/Skt fields are from the IPX packet.
that, if UDP is running over IPXF, the IPX Dest Skt field in
packet header is copied over from IPXF header before the
IPX packet is delivered to UDP, Hence, the pseudo header must
derived from the reassembled IPX header

UDP Length is from UDP header

Note that IPX Src Skt is expected to be 0x9092 for UDP. As such,
may insert 0x9092 in IPX Src Skt field rather than getting the
from IPX header. Then the implementation will not have to check
IPX Src Skt field in the fast path since the checksum failure
also cover the unexpected value. In that case, the
may want to examine if the checksum failure was due to the IPX
Skt value other than 0x9092, so that it can increment
counter, if proprietary counters other than udpInDatagramErr

Sung [Page 12]

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