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