As per Relevance of the word addressing, we have this rfc below:
Network Working Group P.
Request for Comments: 1380 IESG
P.
IESG Internet
November 1992
IESG Deliberations on Routing and
Status Of This
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This memo summarizes issues surrounding the routing and
scaling problems in the IP architecture, and it provides a
background of the ROAD group and related activities in the
Engineering Task Force (IETF).
It also provides a preliminary report of the Internet
Steering Group (IESG) deliberations on how these routing
addressing issues should be pursued in the Internet
Board (IAB)/IETF
This note draws principally from two sources: the output from
ROAD group, as reported at the San Diego IETF meeting, and
numerous detailed discussions in the IESG following the San
IETF meeting. Zheng Wang, Bob Hinden, Kent England, and Bob
provided input for the "Criteria For Bigger Internet Addresses
section below. Greg Vaudreuil prepared the final version of
bibliography, based on previous bibliographies by Lyman Chapin
bibliographies distributed on the Big-Internet mailing list
Table of
1. INTRODUCTION.................................................. 2
2. ISSUES OF GROWTH AND EVOLUTION IN THE INTERNET............... 3
2.1 The Problems................................................ 3
2.2 Possible Solutions.......................................... 5
3. PREPARING FOR ACTION.......................................... 7
3.1 The IAB Architecture Retreats................................ 7
3.2 The Santa Fe IETF............................................ 7
3.3 The ROAD Group and beyond.................................... 8
Gross & Almquist [Page 1]
RFC 1380 ROAD November 1992
4. SETTING DIRECTIONS FOR THE IETF............................... 10
4.1 The Need For Interim Solutions............................... 10
4.2 The Proposed Phases.......................................... 10
4.3 A Solution For Routing Table Explosion -- CIDR............... 12
4.4 Regarding "IP Address Exhaustion"............................ 13
4.5 Milestones And Timetable For Making a Recommendation
"Bigger Internet Addresses".................................. 14
5. SUMMARY....................................................... 15
Appendix A. FOR MORE INFORMATION................................. 16
Appendix B. INFORMATION AND SELECTION CRITERIA FOR "
INTERNET ADDRESSES".................................. 16
Appendix C. BIBLIOGRAPHY......................................... 20
Security Considerations.......................................... 21
Authors' Addresses............................................... 22
1.
It seems unlikely that the designers of IP ever imagined at the
what phenomenal success the Internet would achieve.
connections were initially intended primarily for mainframe
at sites performing DARPA-sponsored research. Now, of course,
Internet has extended its reach to the desktop and is beginning
extend into the home. No longer the exclusive purview of pure R&
establishments, the Internet has become well entrenched in parts
the corporate world and is beginning to make inroads into
and even primary schools. While once it was an almost
U.S. phenomenon, the Internet now extends to every continent
within a few years may well include network connections in
country
Over the past couple of years, we have seen increasingly
indications that all of this success will stress the limits of
unless appropriate corrective actions are taken. The supply
unallocated Class B network numbers is rapidly dwindling, and
amount of routing information now carried in the Internet
increasingly taxing the abilities of both the routers and the
who have to manage them. Somewhat longer-term, it is possible
we will run out of host addresses or network numbers altogether
While these problems could be avoided by attempting to restrict
growth of the Internet, most people would prefer solutions that
growth to continue. Fortunately, it appears that such solutions
possible, and that, in fact, our biggest problem is having too
possible solutions rather than too few
This memo provides a preliminary report of IESG deliberations on
routing and addressing issues can be pursued in the IAB/IETF
Gross & Almquist [Page 2]
RFC 1380 ROAD November 1992
In following sections, we will discuss in more detail the
confronting us and possible approaches. We will give a
overview of the ROAD group and related activities in the IETF.
will then discuss possible courses of action in the IETF
Ultimately, the IESG will issue a recommendation from the IESG/
to the IAB
2. ISSUES OF GROWTH AND EVOLUTION IN THE
2.1 The
The Internet now faces three growth-related problems
- Class B network number exhaustion - Routing table
- IP address space
2.1.1 Class B Network Number
Over the last several years, the number of network numbers
and the number of network numbers configured into the Merit
routing database have roughly doubled every 12 months. This has
to estimates that, at the current allocation rate, and in the
of corrective measures, it will take less than 2 years to
all of the currently unassigned Class B network numbers
After that, new sites which wished to connect more than the number
hosts possible in a single Class C (253 hosts) would need to
assigned multiple Class C networks. This will exacerbate the
table explosion problems described next
2.1.2. Routing Table
As the number of networks connected to the Internet has grown,
amount of routing information that has to be passed around to
track of them all is likewise growing. This is leading to two
of problems
Hardware and Protocol
Routing protocols must pass around this information, and routers
store and use it. This taxes memory limits in the routers, and
also consume significant bandwidth when older routing protocols
used, (such as EGP and RIP, which were designed for a much
number of networks).
The limits on the memory in the routers seem to be the most pressing
It is already the case that the routers used in the MILNET
incapable of handling all of the current routes, and most
Gross & Almquist [Page 3]
RFC 1380 ROAD November 1992
service providers have found the need to periodically upgrade
routers to accommodate ever larger quantities of routing information
An informal survey of router vendors by the ROAD group estimated
most of the currently deployed generation of high-end routers
support O(16000) routes. This will be probably be adequate for
next 12 to 18 months at the current rate of growth. Most
have begun, or will soon begin, to ship routers capable of
O(64000) routes, which should be adequate for an additional two
if the above Class B Network Number Exhaustion problem is solved
Human
The number of routes does not merely tax the network's
plant. Network operators have found that the inter-domain
protocol mechanisms often need to be augmented by a
amount of configuration to make the paths followed by packets
consistent with the policies and desires of the network operators
As the number of networks increases, the configuration (and
traffic monitoring to determine whether the configuration has
done correctly) becomes increasingly difficult and time-consuming
Although it is not possible to determine a number of networks (
therefore a time frame) where human limits will be exceeded,
operators view this as a significant short-term problem
2.1.3. IP Address
If the current exponential growth rate continues unabated, the
of computers connected to the Internet will eventually exceed
number of possible IP addresses. Because IP addresses are
into "network" and "host" portions, we may not ever fully run out
IP addresses because we will run out of IP network numbers first
There is considerable uncertainty regarding the timeframe when
might exceed the limits of the IP address space. However, the
is serious enough that it deserves our earliest attention. It
very important that we develop solutions to this potential
well before we are in danger of actually running out of addresses
2.1.4. Other Internetwork Layer
Although the catalog of problems above is pretty complete as far
the scaling problems of the Internet are concerned, there are
Internet layer issues that will need to be addressed over the
years. These are issues regarding advanced functionality and
guarantees in the Internet layer
In any attempt to resolve the Internet scaling problems, it
Gross & Almquist [Page 4]
RFC 1380 ROAD November 1992
important to consider how these other issues might affect the
evolution of Internet layer protocols. These issues include
1) Policy-based
2) Flow
3) Weak Quality-of-Service (QOS
4) Service guarantees (strong QOS
5)
2.2 Possible
2.2.1. Class B Network Number
A number of approaches have been suggested for how we might slow
exhaustion of the Class B IP addresses. These include
1) Reclaiming those Class B network numbers which have
assigned but are either unused or used by networks which are
connected to the Internet
2) Modifying address assignment policies to slow the
of Class B network numbers by assigning multiple Class C
numbers to organizations which are only a little bit to big to
accommodated by a Class C network number
Note: It is already the case that a Class B number is
only if the applicant would need more than "several" Class
networks. The value of "several" has increased over time
1 to (currently) 32.
3) Use the Class C address space to form aggregations
different size than the normal normal Class C addresses.
schemes include Classless Inter-Domain Routing (CIDR) [Fuller92]
and the C# scheme [Solen92].
2.2.2. Routing Table
As was described earlier, there are actually two parts to
problem. They each have slightly different possible approaches
Hardware and Protocol
1) More thrust. We could simply recognize the fact that
which need full Internet routing information will require
amounts of memory and processing capacity. This is at best a
short-term approach, and we will always need to face this
in the long-term
Gross & Almquist [Page 5]
RFC 1380 ROAD November 1992
2) Route servers (a variant of the "More Thrust" solution).
Instead of requiring every router to store complete
information, mechanisms could be developed to allow the tasks
computing and storing routes to be offloaded to a server.
would request routes from the server as needed (presumably
to improve performance).
3) Topology engineering. Many network providers already try
design their networks in such a way that only a few of the
need complete routing information (the others rely on
routes to reach destinations that they don't have explicit
to). While this is inconvenient for network operators, it is
trend which is likely to continue
It is also the case that network providers could further
the number of routers which need full routing information
accepting some amount of suboptimal routing or reducing
paths used for backup
4) Charging-based solutions. By charging for network
advertisements, it might be possible to discourage sites
connecting more networks to the Internet than they get
value from having connected
5) Aggregation of routing information. It is fairly clear that
the long-term it will be necessary for addresses to be
hierarchical. This will allow routes to many networks to
collapsed into a single summary route. Therefore, an
question is whether aggregation can also be part of the short-
solution. Of the proposals to date, only CIDR could
aggregation in the short-term. All longer-term proposals
aggregation
Human
1) Additional human resources. Network providers could
additional manpower to routing management, or accept
consequences of a reduced level of routing management. This
obviously unattractive as anything other than a very short-
solution
2) Better tools. Network operators and router vendors could
to develop more powerful paradigms and mechanisms for
management
The IETF has already undertaken some work in the areas of
filtering and route leaking
Gross & Almquist [Page 6]
RFC 1380 ROAD November 1992
2.2.3. IP Address
The following general approaches have been suggested for dealing
the possible exhaustion of the IP address space
1) Protocol modifications to provide a larger address space.
enhancing IP or by transitioning to another protocol with a
address space, we could substantially increase the number
available network numbers and addresses
2) Addresses which are not globally unique. Several
schemes have emerged whereby a host's domain name is
unique, but its IP address would be unique only within it's
routing domain. These schemes usually involve address
3) Partitioned Internet. The Internet could be partitioned
areas, such that a host's IP address would be unique only
its own area. Such schemes generally postulate
gateways to interconnect the areas. This is not unlike
approach often used to connect differing protocol families
4) Reclaiming network numbers. Network numbers which are
used, or are used by networks which are not connected to
Internet, could conceivably be reclaimed for general Internet use
This isn't a long-term solution, but could possibly help in
interim if for some reason address exhaustion starts to
unexpectedly soon
3. PREPARING FOR
3.1 The IAB Architecture
In July 1991, the IAB held a special workshop to consider
issues in the IP architecture (Clark91). Of particular concern
the problems related to Internet growth and scaling. The IAB
the issues were of sufficient concern to begin organizing a
group to explore the issues and to explore possible solutions.
Ford (LANL) was asked to organize this effort. The IAB
the architecture workshop in January 1992 to further examine
critical issues, and to meet jointly with the then-formed ROAD
(see below).
3.2 The Santa Fe
At the November 1991 Santa Fe IETF meeting, the BGP Working
independently began a concerted exploration of the issues of
table scaling. The principal approach was to perform
aggregation by using address masks in BGP to do "supernetting
Gross & Almquist [Page 7]
RFC 1380 ROAD November 1992
(rather than "subnetting"). This approach would eventually
into CIDR. The BGP WG decided to form a separate subgroup, to be
by Phill Gross (ANS) to pursue this solution
3.3 The ROAD Group and
At the Santa Fe IETF, the initially separate IAB and BGP
activities were combined into a special effort, named the "
and ADdressing (ROAD) Group", to be co-chaired by Ford and Gross
The group was asked to explore possible near-term approaches for
scaling problems described in the last section, namely
- Class B address
- Routing table
- IP address space
The ROAD group was asked to report back to the IETF at the San
IETF (March 1992). Suggested guidelines included minimizing
to hosts, must be incrementally deployable, and must provide
for a billion networks
The ROAD group was not a traditional open IETF working group. It
always presumed that this was a one-time special group that
lead to the formation of other IETF WGs after its report in
Diego
The ROAD group held several face-face meetings between the
1991 (Santa Fe) and March 1992 (San Diego) IETF meetings.
included several times at the Santa Fe IETF meeting, December 1991
Reston VA, January 1992 in Boston (in conjunction with the
architecture workshop), and January 1992 in Arizona). There was
much discussion by electronic mail
The group produced numerous documents, which have variously been
available as Internet-Drafts or RFCs (see Bibliography in
D).
As follow-up, the ROAD co-chairs reported to the IETF plenary
March 1992 in San Diego. Plus, several specific ROAD-
activities took place during the IETF meeting that week
The Ford/Gross presentation served as a preliminary report from
ROAD group. The basic thrust was
1. The Internet community needs a better way to deal with
addresses (e.g., hierarchical address assignments for
aggregation to help slow Class B exhaustion and routing
Gross & Almquist [Page 8]
RFC 1380 ROAD November 1992
explosion). Classless Inter-Domain Routing (CIDR; also
"supernetting") was recommended. CIDR calls for
- The development of a plan for hierarchical IP
assignment for aggregation in routing
- Enhanced "classless" Inter-domain protocols (i.e.,
address masks along with IP addresses),
- Inter-Domain routing "Usage documents" for using
and routing plan with the enhanced inter-domain protocols
and for interacting with IGPs
2. The Internet community needs bigger addresses for the
to stem IP address exhaustion. The ROAD group explored
approaches in some depth. Some of these approaches were
at the San Diego IETF. However, a final recommendation of
single approach did not emerge
3. The Internet community needs to focus more effort on
directions for Internet routing and advanced Internet
features
Other ROAD-related activities at the San Diego IETF meeting included
- Monday, 8:00 - 9:00 am, Report from the ROAD group
"Internet Routing and Addressing Considerations",
- Monday, 9:30-12:00pm, Geographical Addressing and
(during NOOP WG session),
- Monday, 1:30-3:30pm, Preliminary discussion of a CIDR
and addressing plan (during ORAD session),
- Tuesday, 1:30-6:00pm, Internet Routing and Addressing BOF (
discuss ROAD results and to explore approaches for bigger
address space),
- Wednesday, 1:30-3:30pm, CIDR Supernetting BOF (joint with
WG),
- Thursday, 4:00-6:00pm, Summary of ROAD activities in San
followed by open plenary discussion
The slides for the Monday presentation (Ford92), slides for
Thursday summary (and notes in the Chair's message) (Gross92),
notes for the other sessions are contained in the Proceedings of
Twenty-Third IETF (San Diego).
Gross & Almquist [Page 9]
RFC 1380 ROAD November 1992
4. SETTING DIRECTIONS FOR THE
4.1 The Need For Interim
Solutions to the problems of advanced Internet layer
are far from being well understood. While we should
encourage research in these areas, it is premature to start
engineering effort for an Internet layer which would solve not
the scaling problems but also those other issues
Plus, most approaches to the problem of IP address space
involve changes to the Internet layer. Such approaches mean
changes to host software that will require us to face the
difficult transition of a large installed base
It is therefore not likely that we can (a) develop a single
for the near-term scaling problems that will (b) also solve
longer-term problems of advanced Internet-layer functionality,
we can (c) choose, implement and deploy before the nearer-
problems of Class B exhaustion or routing table explosion
us
This line of reasoning leads to the inevitable conclusion that
will need to make major enhancements to IP in (at least) two stages
Therefore, we will consider interim measures to deal with Class
address exhaustion and routing table explosion (together), and
deal with IP address exhaustion (separately).
We will also suggest that the possible relation between these nearer
term measures and work toward advanced Internet layer
should be made an important consideration
4.2 The Proposed
The IESG recommends that we divide the overall course of action
several phases. For lack of a better vocabulary, we will term
"immediate", "short-term", mid-term", and "long-term" phases. But
as the ROAD group pointed out, we should start all the
immediately. We cannot afford to act on these phases consecutively
In brief, the phases are
- "Immediate". These are configuration and engineering actions
can take place immediately without protocol design, development,
deployment. There are a number of actions that can
immediately. Although none of these will solve any of the problems
they can help slow the onset of the problems
Gross & Almquist [Page 10]
RFC 1380 ROAD November 1992
The IESG specifically endorses
1) the need for more conservative address
policies
2) alignment of new address assignment policies with any
aggregation schemes
3) efforts to reclaim unused Class B addresses
4) installation of more powerful routers by network
at key points in the Internet,
5) careful attention to topology engineering
- "Short-term". Actions in this phase are aimed at dealing
Class B exhaustion and routing table explosion. These problems
deemed to be quite pressing and to need solutions well before the
address exhaustion problem needs to be or could be solved. In
timeframe, changes to hosts can *not* be considered
- "Mid-term". In the mid-term, the issue of IP address
must be solved. This is the most fundamental problem facing the
architecture. Depending on the expected timeframe, changes to
software could be considered. Note: whatever approach is taken,
must also deal with the routing table explosion. If it does not
then we will simply be forced to deal with that problem again, but
a larger address space
- "Long-term". Taking a broader view, the IESG feels that
Internet layer functionality, like QOS support and
reservation, will be crucial to the long-term success of the
architecture
Therefore, planning for advanced Internet layer functionality
play a key role in our choice of mid-term solutions
In particular, we need to keep several things in mind
1) The long-term solution will require replacement and/
extension of the Internet layer. This will be a
trauma for vendors, operators, and for users. Therefore, it
particularly important that we either minimize the trauma
in deploying the sort-and mid-term solutions, or we need to
that the short- and mid-term solutions will provide a
transition path for the long-term solutions
2) The long-term solution will likely require globally
endpoint identifiers with an hierarchical structure to
routing. Any effort to define hierarchy and assignment
for short- or mid-term solutions would, if done well,
have long-term usefulness, even if the long-term solution
Gross & Almquist [Page 11]
RFC 1380 ROAD November 1992
radically different message formats
3) To some extent, development and deployment of the
measures will divert resources away from other important projects
including the development of the long-term solution.
diversion should be carefully considered when choosing
interim measures to pursue
4.3 A Solution For Routing Table Explosion --
The IESG accepted ROAD's endorsement of CIDR [Fuller92]. CIDR
the routing table explosion problem (for the current IP
scheme), makes the Class B exhaustion problem less important,
buys time for the crucial address exhaustion problem
The IESG felt that other alternatives (e.g., C#, see Solen92) did
provide both routing table aggregation and Class B conservation
comparable effort
CIDR will require policy changes, protocol specification changes
implementation, and deployment of new router software, but it
not call for changes to host software
The IESG recommends the following course of action to pursue CIDR
the IETF
a. Adopt the CIDR model described in Fuller92.
b. Develop a plan for "IP Address Assignment Guidelines".
The IESG considered the creation of an addressing plan to be
operational issue. Therefore, the IESG asked Bernhard
(IESG Operational Requirements Area Co-Director) to lead an
to develop such a plan. Bernhard Stockman is in a position
bring important international input (Stockman92) into this
because he is a key player in RIPE and EBONE and he is a co-
of the Intercontinental Engineering Planning Group (IEPG).
A specific proposal [Gerich92] has now emerged. [Gerich92]
incorporates the views of the IETF, RIPE, IEPG, and the
Engineering Planning group (FEPG).
c. Pursue CIDR extensions to BGP in the BGP WG
This activity stated at the San Diego IETF meeting. A new
specification, BGP4, incorporating the CIDR extensions, is
available for public comment [Rekhter92a].
Gross & Almquist [Page 12]
RFC 1380 ROAD November 1992
d. Form a new WG to consider CIDR-related extensions to
(e.g., specify how run IDRP for IP inter-domain routing).
e. Give careful consideration to how CIDR will be deployed in
Internet
This includes issues such as how to maintain address
across non-CIDR domains and how CIDR and various IGPs will need
interact. Depending on the status of the combined
activities, the IESG may recommend forming a "CIDR Deployment WG",
along the same lines as the current BGP Deployment WG
4.4 Regarding "Bigger Internet Addresses
In April-May 1992, the IESG reviewed the various approaches
from the ROAD group activities -- e.g., "Simple CLNP" [Callon92a],
"IP Encaps" [Hinden92], "CNAT" [Callon92b], and "Nimrod
[Chiappa91].
(Note: These were the only proposals under serious consideration
this time period. Other proposals, namely "The P Internet
(PIP)" [Tsuchiya92b] and "The Simple Internet Protocol (SIP)"
[Deering92] have since been proposed. Following the San Diego
deliberations in March, "Simple CLNP" evolved into "TCP and UDP
Bigger Addresses (TUBA)", and "IP Encaps" evolved into "IP
Encapsulation (IPAE)" [Hinden92].)
The "Simple CLNP" approach perhaps initially enjoyed more
than other approaches
However, the consensus view in the IESG was that the full impact
transition to "Simple CLNP" (or to any of the proposed approaches
had not yet been explored in sufficient detail to make a
recommendation possible at this time
The feeling in the IESG was that such important issues
- impact on operational infrastructure
- impact on current protocols (e.g., checksum
in TCP and UDP under any new IP-level protocol),
- deployment of new routing protocols
- assignment of new addresses
- impact on performance
- ownership of change
- effect of supporting new protocols, such as for
resolution
- effect on network management and security,
- the costs to network operators and network users who
Gross & Almquist [Page 13]
RFC 1380 ROAD November 1992
be trained in the architecture and specifics of any
protocols needed to be explored in more depth before
decision of this magnitude should be made
At first the question seemed to be one of timing
At the risk of oversimplifying some very wide ranging discussions
many in the IESG felt that if a decision had to be
*immediately*, then "Simple CLNP" might be their choice. However
they would feel much more comfortable if more detailed
was part of the decision
The IESG felt there needed to be an open and thorough evaluation
any proposed new routing and addressing architecture. The
community must have a thorough understanding of the impact
changing from the current IP architecture to a new one.
community needs to be confident that we all understand which
has the most benefits for long-term internet growth and evolution
and the least impact on the current Internet
The IESG considered what additional information and criteria
needed to choose between alternative approaches. We also
the time needed for gathering this additional information and
amount of time remaining before it was absolutely imperative to
this decision (i.e., how much time do we have before we are in
of running out of IP addresses *before* we could deploy a
architecture?).
This led the IESG to propose a specific set of selection criteria
information, and specific milestones and timetable for the decision
The next section describes the milestones and timetable for
the approach for bigger Internet addresses
The selection criteria referenced in the milestones are contained
Appendix B
4.5 Milestones And Timetable For Making a Recommendation for "
Internet Addresses
In June, the IESG recommended that a call for proposals be made,
initial activities to begin at the July IETF in Boston, and with
strict timetable for reaching a recommendation coming out of
November IETF meeting [Gross92a].
Eventually, the call for proposals was made at the July
itself
Gross & Almquist [Page 14]
RFC 1380 ROAD November 1992
A working group will be formed for each proposed approach.
charter of each WG will be to explore the criteria described
Appendix B and to develop a detailed plan for IESG consideration
The WGs will be asked to submit an Internet-Draft prior to
November 1992 IETF, and to make presentations at the November IETF
The IESG and the IETF will review all submitted proposals and
the IESG will make a recommendation to the IAB following the
1992 IETF meeting
Therefore, the milestones and timetable for the IESG to reach
recommendation on bigger Internet addresses are
July 1992 -- Issue a call for proposals at the Boston IETF
to form working groups to explore separate approaches for
Internet addresses
August-November 1992 -- Proposed WGs submit charters,
discussion lists, and begin their deliberations by email and/
face- to-face meetings. Redistribute the IESG
(i.e., this memo). Public review, discussion, and modification
appropriate of the "selection criteria" in Appendix B
October 1992 -- By the end of October, each WG will be required
submit a written description of the approach and how the
are satisfied. This is to insure that these documents
distributed as Internet-Drafts for public review well before
November IETF meeting
November 1992 -- Each WG will be given an opportunity to
its findings in detail at the November 1992 IETF meeting.
on the written documents, the presentations, and
discussions (by email and at the IETF), the IESG will forward
recommendation to the IAB after the November IETF meeting
5.
The problems of Internet scaling and address exhaustion
fundamentally important to the continued health of the
Internet, and to the long-term success of such programs as the U.S
NREN and the European EBONE. Finding and embarking on a course
action is critical. However, the problem is so important that
need a deep understanding of the information and criteria
in Appendix B before a decision is made
With this memo, the IESG re-affirms its earlier recommendation to
IAB that (a) we move CIDR forward in the IETF as described in
4.3, and (b) that we encourage the exploration of other proposals
Gross & Almquist [Page 15]
RFC 1380 ROAD November 1992
a bigger Internet address space according to the timetable in
4.5.
Appendix A. FOR MORE
To become better acquainted with the issues and/or to follow
progress of these activities
- Please see the documents in the Bibliography below
- Join the Big-Internet mailing list where the general
are discussed (big-internet-request@munnari.oz.au).
- Any new WG formed will have an open mailing list. Please
free to join each as they are announced on the IETF
list. The current lists are
PIP: pip-request@thumper.bellcore.
TUBA: tuba-request@lanl.
IPAE: ip-encaps-request@sunroof.eng.sun.
SIP: sip-request@caldera.usc.
- Attend the November IETF in Washington D.C. (where the
will report and the IESG recommendation will begin
its recommendation to the IAB).
Note: In order to receive announcements of
- future IETF meetings and agenda
- new IETF working groups,
- the posting of Internet-Drafts and RFCs
please send a request to join the IETF-Announcement mailing
(ietf-announce-request@nri.reston.va.us).
Appendix B. INFORMATION AND SELECTION CRITERIA FOR "BIGGER
ADDRESSES
This section describes the information and criteria which the
felt that any new routing and addressing proposal should supply.
the community has a chance to comment on these criteria, and as
IESG gets a better understanding of the issues relating to
of a new routing and addressing architecture, this section may
revised and published in a separate document
It is expected that every proposal submitted for consideration
address each item below on an point-by-point basis
Gross & Almquist [Page 16]
RFC 1380 ROAD November 1992
B.1 Description of the Proposed
A complete description of the proposed routing and
architecture should be supplied. This should be at the level
detail where the functionality and complexity of the scheme can
clearly understood. It should describe how the proposal solves
basic problems of IP address exhaustion and router resource overload
B.2 Changes
All changes to existing protocols should be documented and
protocols which need to be developed and/or deployed should
specified and described. This should enumerate all protocols
are not currently in widespread operational deployment in
Internet
Changes should also be grouped by the devices and/or functions
affect. This should include at least the following
- Protocol changes in
- Protocol changes in exterior
- Protocol changes in interior
- Security and Authentication
- Domain name system
- Network management
- Changes required to operations tools (e.g., ping, trace
route, etc.)
- Changes to operational and
The changes should also include if hosts and routers have
current IP addresses changed
The impact and changes to the existing set of TCP/IP protocols
be described. This should include at a minimum
-
-
-
- ARP/
-
-
-
-
-
The impact on protocols which use IP addresses as data should
specifically addressed
Gross & Almquist [Page 17]
RFC 1380 ROAD November 1992
B.3 Implementation
A description of implementation experience with the proposal
be supplied. This should include the how much of the proposal
implemented and hard it was to implement. If it was implemented
modifying existing code, the extent of the modifications should
described
B.4 Large Internet
The proposal should describe how it will scale to support a
internet of a billion networks. It should describe how the
routing and addressing architecture will work to support an
of this size. This should include, as appropriate, a description
the routing hierarchy, how the routing and addressing will
organized, how different layers of the routing interact (e.g.,
interior and exterior, or L1, L2, L3, etc.), and relationship
addressing and routing
The addressing proposed should include a description of how
will be assigned, who owns the addresses (e.g., user or
provider), and whether there are restrictions in address
or topology
B.5 Syntax and semantics of names, identifiers and
Proposals should address the manner in which data sources and
are identified and addressed, describe how current domain names
IP addresses would be used/translated/mapped in their scheme,
proposed new identifier and address fields and semantics are used
and should describe the issues involved in administration of these
and address spaces according to their proposal. The deployment
should address how these new semantics would be introduced
backward compatibility maintained
Any overlays in the syntax of these protocol structures should
clearly identified and conflicts resulting from syntactic overlay
functionality should be clearly addressed in the discussion of
impact on administrative assignment
B.6 Performance
The performance impact of the new routing and addressing
should be evaluated. It should be compared against the current
of the art with the current IP. The performance evaluation
routers and hosts should include packets-per-second and memory
projections, and bandwidth usage for networks. Performance should
evaluated for both high speed speed and low speed lines
Gross & Almquist [Page 18]
RFC 1380 ROAD November 1992
Performance for routers (table size and computational load)
network bandwidth consumption should be projected based on
following projected data points
-Domains 10^3 10^4 10^5 10^6 10^7 10^8
-Networks 10^4 10^5 10^6 10^7 10^8 10^9
-Hosts 10^6 10^7 10^8 10^9 10^10 10^11
B.7 Support for TCP/IP hosts than do not support the new
The proposal should describe how hosts which do not support the
architecture will be supported -- whether they receive full
and can communicate with the whole Internet, or if they will
limited services. Also, describe if a translation service
provided between old and new hosts? If so, where will be this
done
B.8 Effect on User
The large and growing installed base of IP systems comprises people
as well as software and machines. The proposal should
changes in understanding and procedures that are used by the
involved in internetworking. This should include new and/or
in concepts, terminology, and organization
B.9 Deployment Plan
The proposal should include a deployment plan. It should include
steps required to deploy it. Each step should include the
and protocols which are required to change and what benefits
derived at each step. This should also include at each step if
and routers are required to run the current and proposed
protocol
A schedule should be included, with justification showing that
schedule is realistic
B.10 Security
The impact on current and future security plans should be addressed
Specifically do current security mechanisms such as address
protocol port filtering work in the same manner as they do today,
what is the effect on security and authentication schemes
under development
B.11 Future
The proposal should describe how it lays a foundation for
Gross & Almquist [Page 19]
RFC 1380 ROAD November 1992
emerging internet problems such as security/authentication, mobility
resource allocation, accounting, high packet rates, etc
Appendix C.
-Documents and Information from IETF/IESG
[Ford92] Ford, P., and P. Gross, "Routing And
Considerations", Proceedings of the Twenty-Third IETF, March 1992.
[Gross92] Gross, P., "Chair's Message and Minutes of the Open
Plenary", Proceedings of the Twenty-Third IETF, March 1992.
[Gross92a] Gross, P., "IESG Deliberations on Routing and Addressing",
Electronic mail message to the Big-Internet mailing list, June 1992.
-Documents directly resulting from the ROAD group
[Fuller92] Fuller, V., Li, T., Yu, J., and K. Varadhan
"Supernetting: an Address Assignment and Aggregation Strategy",
1338, BARRNet, cisco, Merit, OARnet, June 1992.
[Hinden92] Hinden, B., "New Scheme for Internet Routing
Addressing (ENCAPS)", Email message to Big-Internet mailing list
March 16, 1992.
[Callon92a] Callon, R., "TCP and UDP with Bigger Addresses (TUBA),
Simple Proposal for Internet Addressing and Routing", RFC 1347, DEC
June 1992
[Deering92] Deering, S., "City Codes: An Alternative Scheme for
NSAP Allocation in the Internet", Email message to Big-
mailing list, January 7, 1992.
[Callon92b]
-Related Documents
[Hinden92b] Hinden, R., and D. Crocker, "A Proposal for IP
Encapsulation (IPAE): A Compatible version of IP with
Addresses", Work in Progress, June 1992.
[Deering92b] Deering, S., "The Simple Internet Protocol", Big
Internet mailing list
[Stockman92] Karrenberg, D., and B. Stockman, "A Proposal for
Global Internet Addressing Scheme", Work in Progress, May 1992.
Gross & Almquist [Page 20]
RFC 1380 ROAD November 1992
[Rekhter92] Rekhter, Y., and T. Li, "Guidelines for IP
Allocation", Work in Progress, May 1992.
[Rekhter92b] Rekhter, Y., and T. Li, "The Border Gateway
(Version 4)", Work in Progress, September 1992.
[Rekhter92c] Rekhter, Y., and P. Gross, "Application of the
Gateway Protocol", Work in Progress, September 1992.
[Gerich92] Gerich, E., "Guidelines for Management of IP
Space", RFC 1366, Merit, October 1992.
[Solen92] Solensky, F., and F. Kastenholz, "A Revision to IP
Classifications", Work in Progress, March 1992.
[Wang92] Wany, Z., and J. Crowcroft, "A Two-Tier Address
for the Internet: A Solution to the Problem of Address
Exhaustion", RFC 1335, University College London, May 1992.
[Callon91] Callon, R., Gardner, E., and R. Colella, "Guidelines
OSI NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC
July 1991.
[Tsuchiya92a] Tsuchiya, P., "The IP Network Address
(NAT): Preliminary Design", Work in Progress, April 1991.
[Tsuchiya92b] Tsuchiya, P., "The 'P' Internet Protocol", Work
Progress, May 1992.
[Chiappa91] Chiappa, J., "A New IP Routing and
Architecture", Work in Progress, July 1991.
[Clark91] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby
"Towards the Future Internet Architecture", RFC 1287, MIT, BBN, CNRI
ISI, UCDavis, December 1991.
Security
Security issues are discussed in sections 4.4, B.2, B.10, and B.11.
Gross & Almquist [Page 21]
RFC 1380 ROAD November 1992
Authors'
Phillip Gross, IESG
Advanced Network &
100 Clearbrook
Elmsford,
Phone: 914-789-5300
EMail: pgross@ans.
Philip
Stanford
Networking
Pine Hall 147
Stanford, CA 94305
Phone: (415) 723-2229
EMail: Almquist@JESSICA.STANFORD.
Gross & Almquist [Page 22]
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
