As per Relevance of the word globally, we have this rfc below:
Network Working Group E.
Request for Comments: 1627 Silicon Graphics, Inc
Category: Informational E.
Apple Computer, Inc
D.
Silicon Graphics, Inc
T.
Sun Microsystems, Inc
July 1994
Network 10 Considered
(Some Practices Shouldn't be Codified
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
Re-use of Internet addresses for private IP networks is the topic
the recent RFC 1597 [1]. It reserves a set of IP network numbers
for (re-)use by any number of organizations, so long as
networks are not routed outside any single, private IP network.
1597 departs from the basic architectural rule that IP addresses
be globally unique, and it does so without having had the benefit
the usual, public review and approval by the IETF or IAB.
document restates the arguments for maintaining a unique
space. Concerns for Internet architecture and operations, as well
IETF procedure, are explored
Growth in use of Internet technology and in attachments to
Internet have taken us to the point that we now are in danger
running out of unassigned IP network numbers. Initially,
were formally assigned only when a network was about to be
to the Internet. This caused difficulties when initial use of
substantially preceded the decision and permission to attach to
Internet. In particular, re-numbering was painful. The lesson
we learned was that every IP address ought to be globally unique
independent of its attachment to the Internet. This makes
possible for any two network entities to communicate, no matter
either might be located. This model is the result of a decades-
evolution, through which the community realized how painful it can
to convert a network of computers to use an assigned number
Lear, Fair, Crocker & Kessler [Page 1]
RFC 1627 Network 10 Considered Harmful July 1994
using random or default addresses found on computers just out of
box. RFC 1597 abrogates this model without benefit of general
community discussion and consensus, leaving policy and
questions unasked and unanswered
KEEP OUR EYES ON THE PRIZE: AN ARCHITECTURAL GOAL AND
A common -- if not universal -- ideal for the future of IP is
every system to be globally accessible, given the proper
mechanisms. Whether such systems comprise toasters, light switches
utility power poles, field medical equipment, or the classic
of "computers", our current model of assignment is to ensure
they can interoperate
In order for such a model to work there must exist a globally
addressing system. A common complaint throughout the community
that the existing security in host software does not allow for
(or even many) hosts in a corporate environment to have direct
access. When this problem is addressed through proper privacy
authentication standards, non-unique IP addresses will become
bottleneck to easy deployment if the recommendations in RFC 1597
followed
The IP version 4 (IPv4) address space will be exhausted.
question is simply: when
If we assert that all IP addresses must be unique globally,
or not, then we will run out of IP address space soon
If we assert that only IP addresses used on the world-wide
need to be globally unique, then we will run out of IP address
later
It is absolutely key to keep the Internet community's
focused on the efforts toward IP next generation (IPng), so that
may transcend the limitations of IPv4. RFC 1597 produces
relief from IPv4 address space exhaustion by masking those
that are not connecting to the Internet, today. However,
apparent relief will likely produce two results: complacency on
large part of the community that does not take the long term view
and a very sudden IP address space exhaustion at some later date
Prior to IPng deployment, it is important to preserve all
semantics that make both the Internet and Internet technology so
valuable for interoperability. Apple Computer, IBM, and
could not collaborate as easily as they have to produce the
without uniquely assigned IP addresses. The same can be said of
Silicon Graphics merger with MIPS. There are many, many more
Lear, Fair, Crocker & Kessler [Page 2]
RFC 1627 Network 10 Considered Harmful July 1994
that can be cited
It should be noted that a scheme similar to RFC 1597 can
implemented at the time that we actually run out of assignable IPv
address space; it simply requires that those organizations which
been assigned addresses but are not yet connected to the
return their addresses to IANA. It is important that the IAB (
IANA as its agent) reassert their ownership of the IP address
now, to preclude challenges to this type of reassignment
OPERATIONAL
RFC 1597
Methods are needed to ensure that the remaining addresses
allocated and used frugally. Due to the current problems,
service providers have made it increasingly difficult
organizations to acquire public IP network numbers. Private
have always had the option of using addresses not assigned to them
appropriate authorities. We do not know how many such
exist, because by their nature they do not interact with the
Internet. By using a random address, a company must take some
to ensure it is able to route to the properly registered owner
that network
RFC 1597 proposes to solve the routing problem by assigning
that will never be used outside of private environments. Using
standard numbers introduces a potential for clashes in another way
If two private networks follow RFC 1597 and then later wish
communicate with each other, one will have to renumber. The
problem occurs if a private network wishes to become public.
likely cost of renumbering is linear to the number of hosts on
network. Thus, a large company with 10,000 hosts on a network
incur considerable expense if it either merged with another
or joined the Internet in such a way as to allow all hosts
directly access the outside network
The probability of address clashes occurring over time approach 100%
with RFC 1597. Picking a random network number reduces the
of having to renumber hosts, but introduces the routing
described above. Best of all, retrieving assigned numbers from
appropriate authority in the first place eliminates both existing
potential address conflicts at the cost of using a part of
address space
Apple Computer once believed that none of its internal systems
ever speak IP directly to the outside world, and as such,
operations picked IP class A network 90 out of thin air to use
Lear, Fair, Crocker & Kessler [Page 3]
RFC 1627 Network 10 Considered Harmful July 1994
Apple is only now recovering from this error, having renumbered
5,000 hosts to provide them with "desktop" Internet access.
the Internet community reaffirms its commitment to a globally
address space, we condemn many thousands of organizations to
pain when they too attempt to answer the call of the global Internet
Another timely example of problems caused by RFC 1597 is Sun's use
Internet multicasting. Sun selectively relays specific
conferences. This has the effect of making many hosts at Sun
to the Internet, even though they are not addressable via IP
routing. If they had non-global addresses this would not work
all. It is not possible to predict which machines need
addresses in advance. Silicon Graphics has a similar configuration
as is likely for others, as well
Some might argue that assigning numbers to use for private
will prevent accidental leaks from occurring through some sort
convention a'la Martian packets. While the proposal attempts
create a standard for "private" address use, there is absolutely
way to ensure that other addresses are not also used
Hence, the "standard" becomes nothing but a misleading heuristic.
fact, it is essential that routers to the global Internet
networks based only on explicit permission, rather than refusing
advertise others based on implicit prohibition, as supported by
policy formally created in RFC 1597.
Security
Administrators will have a hard time spotting unauthorized networks
when their network has been breached (either intentionally
unintentionally) because the other networks might have the
numbers as those normally in the routing tables. More over,
inadvertent connection could possibly have a double whammy effect
partitioning two operational networks
It is worth emphasizing that IP providers should filter out all
authorized networks. Such a practice would not only
accidents but also enhance the security of the Internet by
the potential number of points of attack
Internet multicasting adds a new dimension to security. In
cases it may possible to allow multicasting through firewalls
completely restrict unicast routing. Otherwise unconnected
might well need unique addresses, as illustrated in the
above
Lear, Fair, Crocker & Kessler [Page 4]
RFC 1627 Network 10 Considered Harmful July 1994
Problems with
RFC 1597 gives several examples of IP networks that need not
globally unique address spaces. Each of those cases is plausible
but that does not make it legitimate to ENCOURAGE non-uniqueness
the addresses. In fact, it is equally plausible that globally
IP addresses will be required, for every one of the
described in RFC 1597:
- Airport displays are public information and multicasting beyond
airport might be useful
- An organization's machines which, today, do not need
connectivity might need it tomorrow. Further,
organizations creates havoc when the addresses collide
- Current use of firewalls is an artifact of limitations in
technology. Let's fix the problem, not the symptom
- Inter-organization private links do not generate benefit from
any more correct in guessing which machines want to interact
is true for general Internet access
This is another point that warrants repetition: the belief
administrators can predict which machines will need Internet
is quite simply wrong. We need to reduce or eliminate the
associated with that error, in order to encourage as much
connectivity as operational policies and technical security permit
RFC 1597 works very much against this goal
Problems With "Advantages" And More
RFC 1597 claims that Classless Inter-Domain Routing (CIDR)
require enterprises to renumber their networks. In the general case
this will only involve those networks that are routed outside
enterprises. Since RFC 1597 addresses private enterprise networks
this argument does not apply
The authors mention that DCHP-based tools [2] might help
number transition. However, it is observed that by and large
tools are currently only "potential" in nature
Additionally, with the onslaught of ISDN, slip, and PPP in
implementations, the potential for a workstation to become a
inadvertently has never been greater. Use of a common set
addresses for private networks virtually assures administrators
having their networks partitioned, if they do not take care
carefully control modem connections
Lear, Fair, Crocker & Kessler [Page 5]
RFC 1627 Network 10 Considered Harmful July 1994
Finally, RFC 1597 implies that it may be simple to change a host's
address. For a variety of reasons this may not be the case, and
is not the norm today. For example, a host may be well known
a network. It may have long standing services such as NFS,
would cause problems for clients were its address changed. A
may have software licenses locked by IP address. Thus, migrating
host from private to global addressing may prove difficult. At
very least, one should be careful about addressing well known hosts
POLICY
IANA Has Overstepped Their
For many years, IANA has followed an assignment policy based on
expectation of Internet connectivity for ALL assignees. As such
serves to encourage interconnectivity. IANA assignment of
network numbers listed in RFC 1597 serves to formally
behavior contrary to this accepted practice. Further, this
was effected without benefit of community review and approval
RFC 1597 specifies a new operational requirement explicitly:
service providers must filter the IANA assigned network
listed in RFC 1597 from their routing tables. This address
allocation is permanently removed from being used on the Internet
As we read RFC 1601 [3], this action is not within the purview
IANA, which should only be assigning numbers within the
standards and axioms that underlie the Internet. IP network
are assigned uniquely under the assumption that they will be used
the Internet at some future date. Such assignments violate
axiom, and constitute an architectural change to the Internet.
1602 [4] and RFC 1310 [5] also contain identical wording to
effect in the section that describes IANA
While RFC 1597 contains a view worthy of public debate, it is
ready for formal authorization. Hence, we strongly encourage IANA
withdraw its IP address assignments documented by RFC 1597 forthwith
The IAB should review the address assignment policies and
that compose IANA's mandate, and reaffirm the commitment to
globally unique IP address space
COMMENTS AND
The Internet technology and service is predicated on a global
space. Members of the Internet community have already
and understood the problems and pains associated with
private network number assignments. In effect the proposal
Lear, Fair, Crocker & Kessler [Page 6]
RFC 1627 Network 10 Considered Harmful July 1994
to codify uncoordinated behavior and alter the accepted
addressing model. Hence, it needs to be considered much
thoroughly
RFC 1597 gives the illusion of remedying a problem, by
formal structure to a long-standing informal practice. In fact,
structure distracts us from the need to solve these very
problems and does not even provide substantive aid in the near-term
In the past we have all dreaded the idea of having any part of
address space re-used. Numerous luminaries have both written
spoke at length, explaining why it is we want direct connections
one host to another. Before straying from the current
path, we as a community should revisit the reasoning behind
preaching of unique addressing. While RFC 1597 attempts to
this model, its costs and limitations for enterprises can
enormous, both in the short and long term
[1] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot
"Address Allocation for Private Internets", T.J. Watson
Center, IBM Corp., Chrysler Corp., RIPE NCC, RFC 1597,
1994.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
Bucknell University, October 1993.
[3] Huitema, C., "Charter of the Internet Architecture Board (IAB)",
RFC 1601, IAB, March 1994.
[4] Internet Architecture Board, Internet Engineering
Group, "The Internet Standards Process -- Revision 2", IAB
IESG, RFC 1602, March 1994.
[5] Internet Activities Board, "The Internet Standards Process",
1310, IAB, March 1992.
[6] Internet Activities Board, "Summary of Internet
Discussion", Notes available from ISI, [ftp.isi.edu
pub/IAB/IABmins.jan91Arch.txt], IAB, January 1991.
SECURITY
See the section, "Security Issues".
Lear, Fair, Crocker & Kessler [Page 7]
RFC 1627 Network 10 Considered Harmful July 1994
AUTHORS'
Eliot
Silicon Graphics, Inc
2011 N. Shoreline Blvd
Mountain View,
94043-1389
Phone: +1 415 390 2414
EMail: lear@sgi.
Erik
Apple Computer, Inc
1 Infinite
Cupertino, CA 95014
Phone: +1 408 974 1779
EMail: fair@apple.
Dave
Silicon Graphics, Inc
2011 N. Shoreline Blvd
Mountain View,
94043-1389
Phone: +1 415 390 1804
EMail: dcrocker@sgi.
Thomas
Sun Microsystems Inc
Mail Stop MTV05-44
2550 Garcia Ave
Mountain View, CA 94043
Phone: +1 415 336 3145
EMail: kessler@eng.sun.
Lear, Fair, Crocker & Kessler [Page 8]
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
