As per Relevance of the word broadcast, we have this rfc below:
Network Working Group D.
Request for Comments: 1234 Novell, Inc
June 1991
Tunneling IPX Traffic through IP
Status of this
This memo describes a method of encapsulating IPX datagrams
UDP packets so that IPX traffic can travel across an IP internet
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
Internet Packet eXchange protocol (IPX) is the internetwork
used by Novell's NetWare protocol suite. For the purposes of
paper, IPX is functionally equivalent to the Internet
Protocol (IDP) from the Xerox Network Systems (XNS) protocol
[1]. This memo describes a method of encapsulating IPX
within UDP packets [2] so that IPX traffic can travel across an
internet [3].
This RFC allows an IPX implementation to view an IP internet as
single IPX network. An implementation of this memo will
IPX datagrams in UDP packets in the same way any
implementation might encapsulate IPX datagrams in that hardware'
frames. IPX networks can be connected thusly across internets
carry only IP traffic
Packet
Each IPX datagram is carried in the data portion of a UDP packet
All IP and UDP fields are set normally. Both the source and
destination ports in the UDP packet should be set to the UDP
value allocated by the Internet Assigned Numbers Authority for
implementation of this encapsulation method
As with any UDP application, the transmitting party has the option
avoiding the overhead of the checksum by setting the UDP checksum
zero. Since IPX implementations never use the IPX checksum to
IPX packets from damage, UDP checksumming is highly recommended
IPX encapsulation
Provan [Page 1]
RFC 1234 IPX on IP June 1991
+---------------------+------------+-------------------------------+
| | | | |
| IP Header | UDP Header | IPX Header | IPX packet data |
| (20 or more octets) | (8 octets) | (30 octets) | |
| | | | |
+---------------------+------------+-------------------------------+
Figure 1: An IPX packet carried as data in a UDP packet
Reserved
The first two octets of the IPX header contain the IPX checksum.
packets are never sent with a checksum, so every IPX header
with two octets of FF hex. Implementations of this
scheme should ignore packets with any other value in the first
octets immediately following the UDP header. Other values
reserved for possible future enhancements to this
protocol
Unicast Address
IPX addresses consist of a four octet network number and a six
host number. IPX uses the network number to route each
through the IPX internet to the destination network. Once the
arrives at the destination network, IPX uses the six octet
number as the hardware address on that network
Host numbers are also exchanged in the IPX headers of packets
IPX's Routing Information Protocol (RIP). This supplies end
and routers alike with the hardware address information required
forwarding packets across intermediate networks on the way
the destination networks
For implementations of this memo, the first two octets of the
number will always be zero and the last four octets will be
node's four octet IP address. This makes address mapping trivial
unicast transmissions: the first two octets of the host number
discarded, leaving the normal four octet IP address.
encapsulation code should use this IP address as the
address of the UDP/IP tunnel packet
Broadcasts between Peer
IPX requires broadcast facilities so that NetWare servers and
routers sharing a network can find one another. Since internet-
IP broadcast is neither appropriate nor available, some
mechanism is required. For this memo, each server and router
maintain a list of the IP addresses of the other IPX servers
Provan [Page 2]
RFC 1234 IPX on IP June 1991
routers on the IP internet. I will refer to this list as the "
list", to individual members as "peers", and to all the peers
together, including the local node, as the "peer group". When
requests a broadcast, the encapsulation implementation simulates
broadcast by transmitting a separate unicast packet to each peer
the peer list
Because each peer list is constructed by hand, several groups
peers can share the same IP internet without knowing about
another. This differs from a normal IPX network in which all
would find each other automatically by using the hardware's
facility
The list of peers at each node should contain all other peers in
peer group. In most cases, connectivity will suffer if
from one peer consistently fail to reach some other peer in
group
The peer list could be implemented using IP multicast [4], but
multicast facilities are not widely available at this time, no well
known multicast address has been assigned and no
using multicast exist. As IP multicast is deployed in
implementations, it can be used by simply including in the peer
an IP multicast address for IPX servers and routers. The
multicast address would replace the IP addresses of all peers
will receive IP multicast packets sent from this peer
Broadcasts by
Typically, NetWare client nodes do not need to receive broadcasts,
normally NetWare client nodes on the IP internet would not need to
included in the peer lists at the servers
On the other hand, clients on an IPX network need to send
in order to locate servers and to discover routes. A
implementation of UDP encapsulation can handle this by having
configured list of the IP addresses of all servers and routers in
peer group running on the IP internetwork. As with the peer list
a server, the client implementation would simulate the broadcast
sending a copy of the packet to each IP address in its list of
servers and routers. One of the IP addresses in the list,
the only one, could be a broadcast address or, when available,
multicast address. This allows the client to communicate
members of the peer group without knowing their specific
addresses
It's important to realize that broadcast packets sent from an
client must be able to reach all servers and routers in the
Provan [Page 3]
RFC 1234 IPX on IP June 1991
peer group. Unlike IP, which has a unicast redirect mechanism,
end systems are responsible for discovering routing information
broadcasting a packet requesting a router that can forward packets
the desired destination. If such packets do not tend to reach
entire server peer group, resources in the IPX internet may
visible to an end system, yet unreachable by it
Maximum Transmission
Although larger IPX packets are possible, the standard
transmission unit for IPX is 576 octets. Consequently, 576 octets
the recommended default maximum transmission unit for IPX
being sent with this encapsulation technique. With the eight
UDP header and the 20 octet IP header, the resulting IP packets
be 604 octets long. Note that this is larger than the 576
maximum size IP implementations are required to accept [3]. Any
implementation supporting this encapsulation technique must
capable of receiving 604 octet IP packets
As improvements in protocols and hardware allow for larger
unfragmented IP transmission units, the 576 octet maximum IPX
size may become a liability. For this reason, it is recommended
the IPX maximum transmission unit size be configurable
implementations of this memo
Security
Using a wide-area, general purpose network such as an IP internet
a position normally occupied by physical cabling introduces
security problems not normally encountered in IPX internetworks
Normal media are typically protected physically from outside access
IP internets typically invite outside access
The general effect is that the security of the entire
internetwork is only as good as the security of the entire
internet through which it tunnels. The following broad classes
attacks are possible
1) Unauthorized IPX clients can gain access to resources
normal access control attacks such as password cracking
2) Unauthorized IPX gateways can divert IPX traffic to
routes
3) Unauthorized agents can monitor and manipulate IPX
flowing over physical media used by the IP internet and
control of the agent
Provan [Page 4]
RFC 1234 IPX on IP June 1991
To a large extent, these security risks are typical of the
facing any other application using an IP internet. They
mentioned here only because IPX is not normally suspicious of
media. IPX network administrators will need to be aware of
additional security risks
Assigned
The Internet Assigned Numbers Authority assigns well-known UDP
numbers. It has assigned port number 213 decimal to the
encapsulation technique described in this memo [5].
This encapsulation technique was developed independently by
& Koch and by Novell. I'd like to thank Thomas Ruf of Schneider &
Koch for reviewing this memo to confirm its agreement with
Schneider & Koch implementation and also for his other
suggestions
[1] Xerox, Corp., "Internet Transport Protocols", XSIS 028112,
Corporation, December 1981.
[2] Postel, J., "User Datagram Protocol", RFC 768, USC/
Sciences Institute, August 1980.
[3] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981.
[4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
Stanford University, August 1989.
[5] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-1060,
USC/Information Sciences Institute, March 1990.
Security
See the "Security Issues" section above
Provan [Page 5]
RFC 1234 IPX on IP June 1991
Author's
Don
Novell, Inc
2180 Fortune
San Jose, California, 95131
Phone: (408)473-8440
EMail: donp@Novell.
Provan [Page 6]
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
