As per Relevance of the word addressing, we have this rfc below:
Network Working Group Ross
Request for Comments: 1347
June 1992
TCP and UDP with Bigger Addresses (TUBA),
A Simple Proposal for Internet Addressing and
Status of the
This memo provides information for the Internet community.
does not specify an Internet standard. Distribution of
memo is unlimited
1
The Internet is approaching a situation in which the current
address space is no longer adequate for global
and routing. This is causing problems including: (i)
backbones and regionals are suffering from the need to
large amounts of routing information which is growing rapidly
size (approximately doubling each year); (ii) The Internet
running out of IP network numbers to assign. There is an
need to develop and deploy an approach to addressing and
which solves these problems and allows scaling to several
of magnitude larger than the existing Internet. However, it
necessary for any change to be deployed in an incremental manner
allowing graceful transition from the current Internet
disruption of service. [1]
This paper describes a simple proposal which provides a long-
solution to Internet addressing, routing, and scaling.
involves a gradual migration from the current Internet
(which is based on Internet applications, running over TCP
UDP, running over IP) to an updated suite (based on the
Internet applications, running over TCP or UDP, running over
[2]). This approach is known as "TUBA" (TCP & UDP with
Addresses).
This paper describes a proposal for how transition may
accomplished. Description of the manner in which use of CLNP
NSAP addresses, and related network/Internet layer
(ES-IS, IS-IS, and IDRP) allow scaling to a very large
worldwide Internet is outside of the scope of this paper
Originally, it was thought that any practical proposal needed
address the immediate short-term problem of routing
explosion (in addition to the long-term problem of scaling to
worldwide Internet). Given the current problems caused
excessive routing information in IP backbones, this could
older IP-based systems to talk to other older IP-based
over intervening Internet backbones which did not support IP
This in turn would require either translation of IP packets
Callon [Page 1]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
CLNP packets and vice versa, or encapsulation of IP
inside CLNP packets. However, other shorter-term techniques (
example [3]) have been proposed which will allow the Internet
operate successfully for several years using the current
address space. This in turn allows more time for IP-to-
migration, which in turn allows for a much simpler
technique
The TUBA proposal therefore makes use of a simple long-
migration proposal based on a gradual update of Internet
(to run Internet applications over CLNP) and DNS servers (
return larger addresses). This proposal requires routers to
updated to support forwarding of CLNP (in addition to IP).
However, this proposal does not require encapsulation
translation of packets nor address mapping. IP addresses and
addresses may be assigned and used independently during
migration period. Routing and forwarding of IP and CLNP
may be done independently
This paper provides a draft overview of TUBA. The
operation of TUBA has been left for further study
2 Long-Term Goal of
This proposal seeks to take advantage of the success of
Internet Suite, the greatest part of which is probably the use
IP itself. IP offers a ubiquitous network service, based
datagram (connectionless) operation, and on globally
IP addresses which are structured to aid routing. Unfortunately
the limited 32-bit IP address is gradually becoming
for routing and addressing in a global Internet. Scaling to
anticipated future size of the worldwide Internet requires
larger addresses allowing a multi-level hierarchical
assignment
If we had the luxury of starting over from scratch, most
we would base the Internet on a new datagram internet
with much larger multi-level addresses. In principle, there
many choices available for a new datagram internet protocol.
example, the current IP could be augmented by addition of
addresses, or a new protocol could be developed. However,
development, standardization, implementation, testing,
and deployment of a new protocol (as well as associated
and host-to-router protocols) would take a very large amount
time and energy, and is not guaranteed to lead to success.
addition, there is already such a protocol available.
particular, the ConnectionLess Network Protocol (CLNP [1])
very similar to IP, and offers the required datagram service
address flexibility. CLNP is currently being deployed in
Internet backbones and regionals, and is available in
products. This proposal does not actually require use of
(the main content of this proposal is a graceful migration
from the current IP to a new IP offering a larger address space),
Callon [Page 2]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
but use of CLNP will be assumed
This proposal seeks to minimize the risk associated
migration to a new IP address space. In addition, this
is motivated by the requirement to allow the Internet to scale
which implies use of Internet applications in a very
ubiquitous worldwide Internet. It is therefore proposed
existing Internet transport and application protocols continue
operate unchanged, except for the replacement of 32-bit
addresses with larger addresses. The use of larger addresses
have some effect on applications, particularly on the Domain
Service. TUBA does not mean having to move over to
completely. It would mean only replacing IP with CLNP. TCP, UDP
and the traditional TCP/IP applications would run on top of CLNP
The long term goal of the TUBA proposal involves transition to
worldwide Internet which operates much as the current Internet
but with CLNP replacing IP and with NSAP addresses replacing
addresses. Operation of this updated protocol suite will be
similar to the current operation. For example, in order
initiate communication with another host, a host will obtain
internet address in the same manner that it normally does,
that the address would be larger. In many or most cases,
implies that the host would contact the DNS server, obtain
mapping from the known DNS name to an internet address, and
application packets encapsulated in TCP or UDP, which are in
encapsulated in CLNP. This long term goal requires
specification for how TCP and UDP are run over CLNP. Similarly
DNS servers need to be updated to deal with NSAP addresses,
routers need to be updated to forward CLNP packets. This
does not involve any wider-spread migration to OSI protocols
TUBA does not actually depend upon DNS for its operation.
method that is used for obtaining Internet addresses may
updated to be able to return larger (NSAP) addresses, and
can be used with TUBA
3
Figure 1 illustrates the basic operation of TUBA. Illustrated
a single Internet Routing Domain, which is also
with Internet backbones and/or regionals. Illustrated are two
"updated" Internet Hosts N1 and N2, as well as two older hosts H
and H2, plus a DNS server and two border routers. It is
that the routers internal to the routing domain are capable
forwarding both IP and CLNP traffic (this could be done either
using multi-protocol routers which can forward both
suites, or by using a different set of routers for each suite).
Callon [Page 3]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
................ ................
. H1 . . Internet .
. .-R1-. .
. H2 . . Backbones .
. DNS . . .
. . . and .
. N1 . . .
. . . Regionals .
. N2 .-R2-. .
................ ................
DNS DNS
H IP
N Updated Internet
R Border
Figure 1 - Overview of
Updated Internet hosts talk to old Internet hosts using
current Internet suite unchanged. Updated Internet hosts talk
other updated Internet hosts using (TCP or UDP over) CLNP.
implies that updated Internet hosts must be able to send
old-style packets (using IP), or new style packet (using CLNP).
Which to send is determined via the normal name-to-
lookup
Thus, suppose that host N1 wants to communicate with host H1.
this case, N1 asks its local DNS server for the
associated with H1. In this case, since H1 is a
(not-updated) host, the address available for H1 is an
address, and thus the DNS response returned to N1 specifies an
address. This allows N1 to know that it needs to send a
old-style Internet suite packet (encapsulated in IP) to H1.
Suppose that host N1 wants to communicate with host N2. In
case, again N1 contacts the DNS server. If the routers in
domain have not been updated (to forward CLNP), or if the
resource record for N2 has not been updated, then the DNS
will respond with a normal IP address, and the
between N1 and N2 will use IP (updated hosts in
where the local routers do not handle CLNP are discussed
section 6.3). However, assuming that the routers in the
have been updated (to forward CLNP), that the DNS server has
updated (to be able to return NSAP addresses), and that
appropriate resource records for NSAP addresses have
configured into the DNS server, then the DNS server will
to N1 with the NSAP address for N2, allowing N1 to know to
Callon [Page 4]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
CLNP (instead of IP) for communication with N2.
A new resource record type will be defined for NSAP addresses
New hosts ask for both the new and old (IP address)
records. Older DNS servers will not have the new resource
type, and will therefore respond with only IP
information. Updated DNS servers will have the new
record information for the requested DNS name only if
associated host has been updated (otherwise the updated
server again will respond with an IP address).
Hosts and/or applications which do not use DNS operate in
similar method. For example, suppose that local name to
records are maintained in host table entries on each
workstation. When a workstation is updated to be able to
Internet applications over CLNP, then the host table on the
may also be updated to contain updated NSAP addresses for
hosts which have also been updated. The associated entries
non-updated hosts would continue to contain IP addresses. Thus
again when an updated host wants to initiate communication
another host, it would look up the associated Internet address
the normal manner. If the address returned is a normal 32-bit
address, then the host would initiate a request using an
application over TCP (or UDP) over IP (as at present). If
returned address is a longer NSAP address, then the host
initiate a request using an Internet application over TCP (
UDP) over CLNP
4 Running TCP and UDP Over
TCP is run directly on top of CLNP (i.e., the TCP packet
encapsulated directly inside a CLNP packet - the TCP
occurs directly following the CLNP header). Use of TCP over
is straightforward, with the only non-trivial issue being how
generate the TCP pseudo-header (for use in generating the
checksum).
Note that TUBA runs TCP over CLNP on an end-to-end basis (
example, there is no intention to translate CLNP packets into
packets). This implies that only "consenting updated systems
will be running TCP over CLNP; which in turn implies that,
purposes of generating the TCP pseudoheader from the CLNP header
backward compatibility with existing systems is not an issue
There are therefore several options available for how to
the pseudoheader. The pseudoheader could be set to all
(implying that the TCP header checksum would only be covering
TCP header). Alternatively, the pseudoheader could be
from the CLNP header. For example, the "source address" in
TCP pseudoheader could be replaced with two bytes of zero plus
two byte checksum run on the source NSAP address length
address (and similarly for the destination address);
"protocol" could be replaced by the destination address
value; and the "TCP Length" could be calculated from the
Callon [Page 5]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
packet in the same manner that it is currently calculated
the IP packet. The details of how the pseudoheader is composed
for further study
UDP is transmitted over CLNP in the same manner. In particular
the UDP packet is encapsulated directly inside a CLNP packet
Similarly, the same options are available for the UDP pseudo
header as for the TCP pseudoheader
5 Updates to the Domain Name
TUBA requires that a new DNS resource record entry
("long-address") be defined, to store longer Internet (i.e.,
NSAP) addresses. This resource record allows mapping from
names to NSAP addresses, and will contain entries for
which are able to run Internet applications, over TCP or UDP
over CLNP
The presence of a "long-address" resource record for mapping
particular DNS name to a particular NSAP address can be used
imply that the associated system is an updated Internet host
This specifically does not imply that the system is capable
running OSI protocols for any other purpose. Also, the
address used for running Internet applications (over TCP or
over CLNP) does not need to have any relationship with other
addresses which may be assigned to the same host. For example,
"dual stack" host may be able to run Internet applications
TCP over CLNP, and may also be able to run OSI applications
TP4 over CLNP. Such a host may have a single NSAP
assigned (which is used for both purposes), or may have
NSAP addresses assigned for the two protocol stacks.
"long-address" resource record, if present, may be assumed
contain the correct NSAP address for running Internet
over CLNP, but may not be assumed to contain the correct
address for any other purpose
The backward translation (from NSAP address to DNS name)
facilitated by definition of an associated resource record.
resource record is known as "long-in-addr.arpa", and is used in
manner analogous to the existing "in-addr.arpa".
Updated Internet hosts, when initiating communication
another host, need to know whether that host has been updated
The host will request the address-class "internet address",
entry-type "long-address" from its local DNS server. If
local DNS server has not yet been updated, then the long
resource record will not be available, and an error response
be returned. In this case, the updated hosts must then ask
the regular Internet address. This allows updated hosts to
deployed in environments in which the DNS servers have not
been updated
An updated DNS server, if asked for the long-
Callon [Page 6]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
corresponding to a particular DNS name, does a normal DNS
to obtain the information. If the long-address corresponding
that name is not available, then the updated DNS server
return the resource record type containing the normal 32-bit
address (if available). This allows more efficient
between updated hosts and old hosts in an environment in
the DNS servers have been updated
Interactions between DNS servers can be done over either IP
CLNP, in a manner analogous to interactions between hosts.
servers currently maintain entries in their databases which
them to find IP addresses of other DNS servers. These can
updated to include a combination of IP addresses and
addresses of other servers. If an NSAP address is available,
the communication with the other DNS server can use CLNP
otherwise the interaction between DNS servers uses IP. Initially
it is likely that all communication between DNS servers will
IP (as at present). During the migration process, the DNS
can be updated to communicate with each other using CLNP
6 Other Technical
6.1 When 32-Bit IP Addresses
Eventually, the IP address space will become inadequate
global routing and addressing. At this point, the remaining
(not yet updated) IP hosts will not be able to
directly over the global Internet. This time can be postponed
careful allocation of IP addresses and use of "
Inter-Domain Routing" (CIDR [3]), and if necessary
encapsulation (either of IP in IP, or IP in CLNP). In addition
the number of hosts affected by this can be minimized
aggressive deployment of updated software based on TUBA
When the IP address space becomes inadequate for global
and addressing, for purposes of IP addressing the Internet
need to be split into "IP address domains". 32-bit IP
will be meaningful only within an address domain, allowing
old IP hosts to continue to be used locally. For
between domains, there are two possibilities: (i) The user at
old system can use application layer relays (such as mail
for 822 mail, or by Telnetting to an updated system in order
allow Telnet or FTP to a remote system in another domain);
(ii) Network Address Translation can be used [4].
6.2 Applications which use IP Addresses
There are some application protocols (such as FTP and NFS)
pass around and use IP addresses internally. Migration to
larger address space (whether based on CLNP or other protocol
will require either that these applications be limited to
use (within an "IP address domain" in which 32-bit IP
are meaningful) or be updated to either: (i) Use larger
Callon [Page 7]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
addresses instead of 32-bit IP addresses; or (ii) Use some
globally-significant identifiers, such as DNS names
6.3 Updated Hosts in IP-Only
There may be some updated Internet hosts which are deployed
networks that do not yet have CLNP service, or where CLNP
is available locally, but not to the global Internet. In
cases, it will be necessary for the updated Internet hosts
know to initially send all Internet traffic (or all non-
traffic) using IP, even when the remote system also has
updated. There are several ways that this can be accomplished
such as: (i) The host could contains a manual
parameter controlling whether to always use IP, or to use IP
CLNP depending upon remote address; (ii) The DNS resolver on
host could be "lied to" to believe that all remote requests
supposed to go to some particular server, and that server
intervene and change all remote requests for long-addresses
requests for normal IP addresses
6.4 Local Network Address
Network Address Translation (NAT [4]) has been proposed as
means to allow global communication between hosts which
locally-significant IP addresses. NAT requires that IP
be mapped at address domain boundaries, either to
significant addresses, or to local addresses meaningful in
next address domain along the packet's path. It is possible
define a version of NAT which is "local" to an addressing domain
in the sense that (locally significant) IP packets are mapped
globally significant CLNP packets before exiting a domain, in
manner which is transparent to systems outside of the domain
NAT allows old systems to continue to be used globally
application gateways, at the cost of significant
complexity and possibly performance costs (associated
translation or encapsulation of network packets at IP
domain boundaries). NAT does not address the problem
applications which pass around and use IP addresses internally
The details of Network Address Translation is outside of
scope of this document
6.5 Streamlining Operation of
CLNP contains a number of optional and/or variable length fields
For example, CLNP allows addresses to be any integral number
bytes up to 20 bytes in length. It is proposed to "profile"
in order to allow streamlining of router operation. For example
this might involve specifying that all Internet hosts will use
NSAP address of precisely 20 bytes in length, and may
which optional fields (if any) will be present in all
packets. This can allow all CLNP packets transmitted by
Callon [Page 8]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
hosts to use a constant header format, in order to speed
header parsing in routers. The details of the Internet
profile is for further study
7
[1] "The IAB Routing and Addressing Task Force:
Report", work in progress
[2] "Protocol for Providing the Connectionless-Mode
Service", ISO 8473, 1988.
[3] "Supernetting: An Address Assignment and
Strategy", V.Fuller, T.Li, J.Yu, and K.Varadhan, March
1992.
[4] "Extending the IP Internet Through Address Reuse",
Tsuchiya, December 1991.
8 Security
Security issues are not discussed in this memo
9 Author's
Ross
Digital Equipment
550 King Street, LKG 1-2/A19
Littleton, MA 01460-1289
Phone: 508-486-5009
Email: Callon@bigfut.lkg.dec.
Callon [Page 9]
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
