As per Relevance of the word destination, we have this rfc below:
Network Working Group J. Mogul (Stanford
Request for Comments: 950 J. Postel (ISI
August 1985
Internet Standard Subnetting
Status Of This
This RFC specifies a protocol for the ARPA-Internet community.
subnetting is implemented it is strongly recommended that
procedures be followed. Distribution of this memo is unlimited
This memo discusses the utility of "subnets" of Internet networks
which are logically visible sub-sections of a single
network. For administrative or technical reasons, many
have chosen to divide one Internet network into several subnets
instead of acquiring a set of Internet network numbers. This
specifies procedures for the use of subnets. These procedures
for hosts (e.g., workstations). The procedures used in and
subnet gateways are not fully described. Important motivation
background information for a subnetting standard is provided
RFC-940 [7].
This memo is based on RFC-917 [1]. Many people contributed to
development of the concepts described here. J. Noel Chiappa,
Kent, and Tim Mann, in particular, provided important suggestions
Additional contributions in shaping this memo were made by Zaw-
Su, Mike Karels, and the Gateway Algorithms and Data Structures
Force (GADS).
Mogul & Postel [Page 1]
RFC 950 August 1985
Internet Standard Subnetting
1.
The original view of the Internet universe was a two-level hierarchy
the top level the Internet as a whole, and the level below
individual networks, each with its own network number. The
does not have a hierarchical topology, rather the interpretation
addresses is hierarchical. In this two-level model, each host
its network as a single entity; that is, the network may be
as a "black box" to which a set of hosts is connected
While this view has proved simple and powerful, a number
organizations have found it inadequate, and have added a third
to the interpretation of Internet addresses. In this view, a
Internet network is divided into a collection of subnets
The three-level model is useful in networks belonging to
large organizations (e.g., Universities or companies with more
one building), where it is often necessary to use more than one
cable to cover a "local area". Each LAN may then be treated as
subnet
There are several reasons why an organization might use more than
cable to cover a campus
- Different technologies: Especially in a research environment
there may be more than one kind of LAN in use; e.g.,
organization may have some equipment that supports Ethernet,
some that supports a ring network
- Limits of technologies: Most LAN technologies impose limits
based on electrical parameters, on the number of
connected, and on the total length of the cable. It is easy
exceed these limits, especially those on cable length
- Network congestion: It is possible for a small subset of
hosts on a LAN to monopolize most of the bandwidth. A
solution to this problem is to divide the hosts into cliques
high mutual communication, and put these cliques on
cables
- Point-to-Point links: Sometimes a "local area", such as
university campus, is split into two locations too far apart
connect using the preferred LAN technology. In this case
high-speed point-to-point links might connect several LANs
An organization that has been forced to use more than one LAN
three choices for assigning Internet addresses
Mogul & Postel [Page 2]
RFC 950 August 1985
Internet Standard Subnetting
1. Acquire a distinct Internet network number for each cable
subnets are not used at all
2. Use a single network number for the entire organization,
assign host numbers without regard to which LAN a host is
("transparent subnets").
3. Use a single network number, and partition the host
space by assigning subnet numbers to the LANs ("
subnets").
Each of these approaches has disadvantages. The first, although
requiring any new or modified protocols, results in an explosion
the size of Internet routing tables. Information about the
details of local connectivity is propagated everywhere, although
is of little or no use outside the local organization. Especially
some current gateway implementations do not have much space
routing tables, it would be good to avoid this problem
The second approach requires some convention or protocol that
the collection of LANs appear to be a single Internet network.
example, this can be done on LANs where each Internet address
translated to a hardware address using an Address Resolution
(ARP), by having the bridges between the LANs intercept ARP
for non-local targets, see RFC-925 [2]. However, it is not
to do this for all LAN technologies, especially those where
protocols are not currently used, or if the LAN does not
broadcasts. A more fundamental problem is that bridges must
which LAN a host is on, perhaps by using a broadcast algorithm.
the number of LANs grows, the cost of broadcasting grows as well
also, the size of translation caches required in the bridges
with the total number of hosts in the network
The third approach is to explicitly support subnets. This does
a disadvantage, in that it is a modification of the
Protocol, and thus requires changes to IP implementations already
use (if these implementations are to be used on a subnetted network).
However, these changes are relatively minor, and once made, yield
simple and efficient solution to the problem. Also, the
avoids any changes that would be incompatible with existing hosts
non-subnetted networks
Further, when appropriate design choices are made, it is possible
hosts which believe they are on a non-subnetted network to be used
a subnetted one, as explained in RFC-917 [1]. This is useful when
is not possible to modify some of the hosts to support
explicitly, or when a gradual transition is preferred
Mogul & Postel [Page 3]
RFC 950 August 1985
Internet Standard Subnetting
2. Standards for Subnet
This section first describes a proposal for interpretation
Internet addresses to support subnets. Next it discusses changes
host software to support subnets. Finally, it presents a
for discovering what address interpretation is in use on a
network (i.e., what address mask is in use).
2.1. Interpretation of Internet
Suppose that an organization has been assigned an Internet
number, has further divided that network into a set of subnets
and wants to assign host addresses: how should this be done
Since there are minimal restrictions on the assignment of
"local address" part of the Internet address, several
have been proposed for representing the subnet number
1. Variable-width field: Any number of the bits of the
address part are used for the subnet number; the size
this field, although constant for a given network,
from network to network. If the field width is zero,
subnets are not in use
2. Fixed-width field: A specific number of bits (e.g., eight
is used for the subnet number, if subnets are in use
3. Self-encoding variable-width field: Just as the
(i.e., class) of the network number field is encoded by
high-order bits, the width of the subnet field is
encoded
4. Self-encoding fixed-width field: A specific number of
is used for the subnet number
5. Masked bits: Use a bit mask ("address mask") to
which bits of the local address field indicate the
number
What criteria can be used to choose one of these five schemes
First, should we use a self-encoding scheme? And, should it
possible to tell from examining an Internet address if it
to a subnetted network, without reference to any
information
An interesting feature of self-encoding is that it allows
Mogul & Postel [Page 4]
RFC 950 August 1985
Internet Standard Subnetting
address space of a network to be divided into subnets
different sizes, typically one subnet of half the address
and a set of small subnets
For example, consider a class C network that uses
self-encoding scheme with one bit to indicate if it is
large subnet or not and an additional three bits to
the small subnet. If the first bit is zero then this is
large subnet, if the first bit is one then the
bits (3 in this example) give the subnet number. There
one subnet with 128 host addresses, and eight subnets
16 hosts each
To establish a subnetting standard the parameters
interpretation of the self-encoding scheme must be fixed
consistent throughout the Internet
It could be assumed that all networks are subnetted.
would allow addresses to be interpreted without reference
any other information
This is a significant advantage, that given the
address no additional information is needed for
implementation to determine if two addresses are on the
subnet. However, this can also be viewed as a disadvantage
it may cause problems for networks which have existing
numbers that use arbitrary bits in the local address part
In other words, it is useful to be able to control whether
network is subnetted independently from the assignment
host addresses
The alternative is to have the fact that a network is
kept separate from the address. If one finds, somehow,
the network is subnetted then the standard self-
subnetted network address rules are followed, otherwise
non-subnetted network addressing rules are followed
If a self-encoding scheme is not used, there is no reason to use
fixed-width field scheme: since there must in any case be
per-network "flag" to indicate if subnets are in use,
additional cost of using an integer (a subnet field width
address mask) instead of a boolean is negligible. The
of using the address mask scheme is that it allows
organization to choose the best way to allocate relatively
bits of local address to subnet and host numbers. Therefore,
choose the address-mask scheme: it is the most flexible scheme
yet costs no more to implement than any other
Mogul & Postel [Page 5]
RFC 950 August 1985
Internet Standard Subnetting
For example, the Internet address might be interpreted as
where the field is as defined by IP [3],
field is at least 1-bit wide, and the width of
field is constant for a given network. No
structure is required for the or
fields. If the width of the field is zero,
the network is not subnetted (i.e., the interpretation of [3]
used).
For example, on a Class B network with a 6-bit wide subnet field
an address would be broken down like this
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0| NETWORK | SUBNET | Host Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Since the bits that identify the subnet are specified by
bitmask, they need not be adjacent in the address. However,
recommend that the subnet bits be contiguous and located as
most significant bits of the local address
Special Addresses
From the Assigned Numbers memo [9]:
"In certain contexts, it is useful to have fixed
with functional significance rather than as identifiers
specific hosts. When such usage is called for, the
zero is to be interpreted as meaning "this", as in "
network". The address of all ones are to be interpreted
meaning "all", as in "all hosts". For example, the
128.9.255.255 could be interpreted as meaning all hosts
the network 128.9. Or, the address 0.0.0.37 could
interpreted as meaning host 37 on this network."
It is useful to preserve and extend the interpretation of
special addresses in subnetted networks. This means the
of all zeros and all ones in the subnet field should not
assigned to actual (physical) subnets
In the example above, the 6-bit wide subnet field may
any value except 0 and 63.
Mogul & Postel [Page 6]
RFC 950 August 1985
Internet Standard Subnetting
Please note that there is no effect or new restriction on
addresses of hosts on non-subnetted networks
2.2. Changes to Host Software to Support
In most implementations of IP, there is code in the module
handles outgoing datagrams to decide if a datagram can be
directly to the destination on the local network or if it must
sent to a gateway
Generally the code is something like this
IF ip_net_number(dg.ip_dest) = ip_net_number(my_ip_addr
send_dg_locally(dg, dg.ip_dest
send_dg_locally(dg
gateway_to(ip_net_number(dg.ip_dest)))
(If the code supports multiply-connected networks, it will be
complicated, but this is irrelevant to the current discussion.)
To support subnets, it is necessary to store one more 32-
quantity, called my_ip_mask. This is a bit-mask with bits set
the fields corresponding to the IP network number, and
bits set corresponding to the subnet number field
The code then becomes
IF bitwise_and(dg.ip_dest, my_ip_mask
= bitwise_and(my_ip_addr, my_ip_mask
send_dg_locally(dg, dg.ip_dest
send_dg_locally(dg
gateway_to(bitwise_and(dg.ip_dest, my_ip_mask)))
Of course, part of the expression in the conditional can
pre-computed
It may or may not be necessary to modify the "gateway_to
function, so that it too takes the subnet field bits into
when performing comparisons
To support multiply-connected hosts, the code can be changed
Mogul & Postel [Page 7]
RFC 950 August 1985
Internet Standard Subnetting
keep the "my_ip_addr" and "my_ip_mask" quantities on
per-interface basis; the expression in the conditional must
be evaluated for each interface
2.3. Finding the Address
How can a host determine what address mask is in use on a
to which it is connected? The problem is analogous to
other "bootstrapping" problems for Internet hosts: how a
determines its own address, and how it locates a gateway on
local network. In all three cases, there are two basic solutions
"hardwired" information, and broadcast-based protocols
Hardwired information is that available to a host in
from a network. It may be compiled-in, or (preferably) stored
a disk file. However, for the increasingly common case of
diskless workstation that is bootloaded over a LAN,
hardwired solution is satisfactory
Instead, since most LAN technology supports broadcasting, a
method is for the newly-booted host to broadcast a request for
necessary information. For example, for the purpose
determining its Internet address, a host may use the "
Address Resolution Protocol" (RARP) [4].
However, since a newly-booted host usually needs to gather
facts (e.g., its IP address, the hardware address of a gateway
the IP address of a domain name server, the subnet address mask),
it would be better to acquire all this information in one
if possible, rather than doing numerous broadcasts on the network
The mechanisms designed to boot diskless workstations can
load per-host specific configuration files that contain
required information (e.g., see RFC-951 [8]). It is possible,
desirable, to obtain all the facts necessary to operate a
from a boot server using only one broadcast message
In the case where it is necessary for a host to find the
mask as a separate operation the following mechanism is provided
To provide the address mask information the ICMP protocol [5]
is extended by adding a new pair of ICMP message types
"Address Mask Request" and "Address Mask Reply", analogous
the "Information Request" and "Information Reply"
messages. These are described in detail in Appendix I
The intended use of these new ICMP messages is that a host
when booting, broadcast an "Address Mask Request" message.
Mogul & Postel [Page 8]
RFC 950 August 1985
Internet Standard Subnetting
gateway (or a host acting in lieu of a gateway) that
this message responds with an "Address Mask Reply". If
is no indication in the request which host sent it (i.e.,
IP Source Address is zero), the reply is broadcast as well
The requesting host will hear the response, and from
determine the address mask
Since there is only one possible value that can be sent in
"Address Mask Reply" on any given LAN, there is no need for
requesting host to match the responses it hears against
request it sent; similarly, there is no problem if more
one gateway responds. We assume that hosts
infrequently, so the broadcast load on a network from use
this protocol should be small
If a host is connected to more than one LAN, it might have to
the address mask for each
One potential problem is what a host should do if it can not
out the address mask, even after a reasonable number of tries
Three interpretations can be placed on the situation
1. The local net exists in (permanent) isolation from all
nets
2. Subnets are not in use, and no host can supply the
mask
3. All gateways on the local net are (temporarily) down
The first and second situations imply that the address mask
identical with the Internet network number mask. In the
situation, there is no way to determine what the proper value is
the safest choice is thus a mask identical with the
network number mask. Although this might later turn out to
wrong, it will not prevent transmissions that would
succeed. It is possible for a host to recover from a
choice: when a gateway comes up, it should broadcast an "
Mask Reply"; when a host receives such a message that
with its guess, it should change its mask to conform to
received value. No host or gateway should send an "Address
Reply" based on a "guessed" value
Finally, note that no host is required to use this ICMP
to discover the address mask; it is perfectly reasonable for
host with non-volatile storage to use stored
(including a configuration file from a boot server).
Mogul & Postel [Page 9]
RFC 950 August 1985
Internet Standard Subnetting
Appendix I. Address Mask
Address Mask Request or Address Mask
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields
The address of the source in an address mask request
will be the destination of the address mask reply message
To form an address mask reply message, the source address
the request becomes the destination address of the reply
the source address of the reply is set to the replier'
address, the type code changed to AM2, the address
value inserted into the Address Mask field, and the
recomputed. However, if the source address in the
message is zero, then the destination address for the
message should denote a broadcast
ICMP Fields
AM1 for address mask request
AM2 for address mask reply
0 for address mask request
0 for address mask reply
The checksum is the 16-bit one's complement of the one'
Mogul & Postel [Page 10]
RFC 950 August 1985
Internet Standard Subnetting
complement sum of the ICMP message starting with the
Type. For computing the checksum, the checksum field
be zero. This checksum may be replaced in the future
An identifier to aid in matching requests and replies,
be zero
Sequence
A sequence number to aid in matching requests and replies
may be zero
Address
A 32-bit mask
A gateway receiving an address mask request should return
with the address mask field set to the 32-bit mask of the
identifying the subnet and network, for the subnet on which
request was received
If the requesting host does not know its own IP address, it
leave the source field zero; the reply should then
broadcast. However, this approach should be avoided if at
possible, since it increases the superfluous broadcast load
the network. Even when the replies are broadcast, since
is only one possible address mask for a subnet, there is
need to match requests with replies. The "Identifier"
"Sequence Number" fields can be ignored
Type AM1 may be received from a gateway or a host
Type AM2 may be received from a gateway, or a host acting
lieu of a gateway
Mogul & Postel [Page 11]
RFC 950 August 1985
Internet Standard Subnetting
Appendix II.
These examples show how a host can find out the address mask
the ICMP Address Mask Request and Address Mask Reply messages.
the following examples, assume that address 255.255.255.255
"broadcast to this physical medium" [6].
1. A Class A Network
For this case, assume that the requesting host is on class
network 36.0.0.0, has address 36.40.0.123, that there is a
at 36.40.0.62, and that a 8-bit wide subnet field is in use,
is, the address mask is 255.255.0.0.
The most efficient method, and the one we recommend, is for a
to first discover its own address (perhaps using "RARP" [4]),
then to send the ICMP request to 255.255.255.255:
Source address: 36.40.0.123
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Mask Request = AM
Code: 0
Mask: 0
The gateway can then respond directly to the requesting host
Source address: 36.40.0.62
Destination address: 36.40.0.123
Protocol: ICMP = 1
Type: Address Mask Reply = AM
Code: 0
Mask: 255.255.0.0
Suppose that 36.40.0.123 is a diskless workstation, and does
know even its own host number. It could send the
datagram
Source address: 0.0.0.0
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Mask Request = AM
Code: 0
Mask: 0
36.40.0.62 will hear the datagram, and should respond with
datagram
Mogul & Postel [Page 12]
RFC 950 August 1985
Internet Standard Subnetting
Source address: 36.40.0.62
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Mask Reply = AM
Code: 0
Mask: 255.255.0.0
Note that the gateway uses the narrowest possible broadcast
reply. Even so, the over use of broadcasts presents
unnecessary load to all hosts on the subnet, and so the use of
"anonymous" (0.0.0.0) source address must be kept to a minimum
If broadcasting is not allowed, we assume that hosts have wired-
information about neighbor gateways; thus, 36.40.0.123 might
this datagram
Source address: 36.40.0.123
Destination address: 36.40.0.62
Protocol: ICMP = 1
Type: Address Mask Request = AM
Code: 0
Mask: 0
36.40.0.62 should respond exactly as in the previous case
Source address: 36.40.0.62
Destination address: 36.40.0.123
Protocol: ICMP = 1
Type: Address Mask Reply = AM
Code: 0
Mask: 255.255.0.0
2. A Class B Network
For this case, assume that the requesting host is on class
network 128.99.0.0, has address 128.99.4.123, that there is
gateway at 128.99.4.62, and that a 6-bit wide subnet field is
use, that is, the address mask is 255.255.252.0.
The host sends the ICMP request to 255.255.255.255:
Source address: 128.99.4.123
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Mask Request = AM
Code: 0
Mask: 0
Mogul & Postel [Page 13]
RFC 950 August 1985
Internet Standard Subnetting
The gateway can then respond directly to the requesting host
Source address: 128.99.4.62
Destination address: 128.99.4.123
Protocol: ICMP = 1
Type: Address Mask Reply = AM
Code: 0
Mask: 255.255.252.0
In the diskless workstation case the host sends
Source address: 0.0.0.0
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Mask Request = AM
Code: 0
Mask: 0
128.99.4.62 will hear the datagram, and should respond with
datagram
Source address: 128.99.4.62
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Mask Reply = AM
Code: 0
Mask: 255.255.252.0
If broadcasting is not allowed 128.99.4.123 sends
Source address: 128.99.4.123
Destination address: 128.99.4.62
Protocol: ICMP = 1
Type: Address Mask Request = AM
Code: 0
Mask: 0
128.99.4.62 should respond exactly as in the previous case
Source address: 128.99.4.62
Destination address: 128.99.4.123
Protocol: ICMP = 1
Type: Address Mask Reply = AM
Code: 0
Mask: 255.255.252.0
Mogul & Postel [Page 14]
RFC 950 August 1985
Internet Standard Subnetting
3. A Class C Network Case (illustrating non-contiguous subnet bits
For this case, assume that the requesting host is on class
network 192.1.127.0, has address 192.1.127.19, that there is
gateway at 192.1.127.50, and that on network an 3-bit subnet
is in use (01011000), that is, the address mask is 255.255.255.88.
The host sends the ICMP request to 255.255.255.255:
Source address: 192.1.127.19
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Mask Request = AM
Code: 0
Mask: 0
The gateway can then respond directly to the requesting host
Source address: 192.1.127.50
Destination address: 192.1.127.19
Protocol: ICMP = 1
Type: Address Mask Reply = AM
Code: 0
Mask: 255.255.255.88.
In the diskless workstation case the host sends
Source address: 0.0.0.0
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Mask Request = AM
Code: 0
Mask: 0
192.1.127.50 will hear the datagram, and should respond with
datagram
Source address: 192.1.127.50
Destination address: 255.255.255.255
Protocol: ICMP = 1
Type: Address Mask Reply = AM
Code: 0
Mask: 255.255.255.88.
If broadcasting is not allowed 192.1.127.19 sends
Mogul & Postel [Page 15]
RFC 950 August 1985
Internet Standard Subnetting
Source address: 192.1.127.19
Destination address: 192.1.127.50
Protocol: ICMP = 1
Type: Address Mask Request = AM
Code: 0
Mask: 0
192.1.127.50 should respond exactly as in the previous case
Source address: 192.1.127.50
Destination address: 192.1.127.19
Protocol: ICMP = 1
Type: Address Mask Reply = AM
Code: 0
Mask: 255.255.255.88
Appendix III.
A node connected to two or more administratively
but physically distinct subnets, that automatically
datagrams when necessary, but whose existence is not known
other hosts. Also called a "software repeater".
A node connected to two or more administratively distinct
and/or subnets, to which hosts send datagrams to be forwarded
Host
The bit field in an Internet address used for denoting a
host
The collection of connected networks using the IP protocol
Local
The rest field of the Internet address (as defined in [3]).
A single Internet network (which may or may not be divided
subnets).
Mogul & Postel [Page 16]
RFC 950 August 1985
Internet Standard Subnetting
Network
The network field of the Internet address
One or more physical networks forming a subset of an
network. A subnet is explicitly identified in the
address
Subnet
The bit field in an Internet address denoting the subnet number
The bits making up this field are not necessarily contiguous
the address
Subnet
A number identifying a subnet within a network
Appendix IV. Assigned
The following assignments are made for protocol parameters used
the support of subnets. The only assignments needed are for
Internet Control Message Protocol (ICMP) [5].
ICMP Message
AM1 = 17
AM2 = 18
Mogul & Postel [Page 17]
RFC 950 August 1985
Internet Standard Subnetting
[1] Mogul, J., "Internet Subnets", RFC-917, Stanford University
October 1984.
[2] Postel, J., "Multi-LAN Address Resolution", RFC-925,
USC/Information Sciences Institute, October 1984.
[3] Postel, J., "Internet Protocol", RFC-791, USC/
Sciences Institute, September 1981.
[4] Finlayson, R., T. Mann, J. Mogul, M. Theimer, "A Reverse
Resolution Protocol", RFC-903, Stanford University, June 1984.
[5] Postel, J., "Internet Control Message Protocol", RFC-792,
USC/Information Sciences Institute, September 1981.
[6] Mogul, J., "Broadcasting Internet Datagrams", RFC-919,
University, October 1984.
[7] GADS, "Towards an Internet Standard Scheme for Subnetting",
RFC-940, Network Information Center, SRI International
April 1985.
[8] Croft, B., and J. Gilmore, "BOOTP -- UDP Bootstrap Protocol",
RFC-951, Stanford University, August 1985.
[9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-943,
USC/Information Sciences Institute, April 1985.
Mogul & Postel [Page 18]
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
