Internet Draft Internet Architecture Board
July 1992
Expires: January 1993
IP Version 7
**DRAFT 8**
Status of this Memo
This document is an Internet Draft. 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.
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 1id-abstracts.txt listing contained in the internet-
drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com, or munnari.oz.auto to learn the current status of
any Internet Draft.
Abstract
Internet growth has created serious problems of address space
consumption and routing information explosion. A solution to these
problems requires a new version of the Internet Protocol, which we
call IP version 7 ("IPv7"). This memo presents architectural
guidelines that any IPv7 should meet. It then discusses how an IPv7
based upon the OSI CLNP protocol would meet these requirements, and
presents the reasons for the IAB's preference for this solution.
Finally, it makes a three-part recommendation: (1) proceed at full
speed on CIDR; (2) do the design work on IPv7 based on CLNP; and (3)
continue to pursue research in advanced routing and other future
extensions of the Internet architecture.
TABLE OF CONTENTS
1. INTRODUCTION .................................................. 2
2. ARCHITECTURAL PRINCIPLES ...................................... 4
3. POSSIBLE APPROACHES TO IPv7 ................................... 9
4. RESEARCH AREAS ................................................ 13
5. THE WAY FORWARD ............................................... 14
REFERENCES ....................................................... 15
IAB [Page 1]
Internet Draft IP v7 July 1992
1. INTRODUCTION
1.1 The Need for IPv7
The rapid growth of the Internet has exposed the consequences of a
design choice made 15 years ago, the choice of a fixed-length 32-
bit address field for IP [IEN-005]. At that time, 32 bits appeared
to be a very wide field, allowing many thousands of networks and
millions of hosts, several orders of magnitude beyond the likely
size of the Internet. However, the Internet has now grown to this
order of magnitude, leading to two different scaling problems:
* Routing Information Explosion
The cost and complexity of Internet routing grow very rapidly
with the number of networks. This growth is creating
increasingly serious operational problems.
* Address Space Consumption
Current IP addresses are 32 bits. While this seems to be a
very large number (4*10**9), its division into host and
network parts and into class A, B, and C networks
significantly reduces the available space. Projections are
difficult and highly arguable, but at the current rate of
growth, the existing space may be used up in the foreseeable
future.
We believe that the current Internet Protocol, version 4 ("IPv4"),
cannot practically be extended to solve these problems, and that a
new version of IP is needed. We follow current nomenclature by
calling the next generation Internet Protocol "IP version 7" or
"IPv7".
1.2 History
The IAB took its first step towards considering the IP scaling
problems during a workshop on "The Future of the Internet
Architecture" in July 1991. [RFC-1287]. The results of this
group's deliberations were reported to the November 1991 IETF
meeting. Partly as an IAB initiative and partly as a result of
internal IETF working group discussions, a task group known as
"ROAD" was formed in November 1991. This group worked very
intensively for the following three months, with the mandate of
developing one or more plausible architectural starting points for
attacking the scaling problems. Although the ROAD group did not
reach a definitive recommendation, it turned out to be enormously
helpful in structuring the problem, and laid the groundwork for
IAB [Page 2]
Internet Draft IP v7 July 1992
this memo [ROAD].
More recently, there has been an intense debate on various mailing
lists and a profusion of new suggestions. Each of these reflects
careful thought by informed people. All of this prior work has
been factored into the contents of this document. In particular, a
recent paper by Callon [TUBA] is very complementary to our
discussion in Section 3.
This document presents a summary of the IAB's analysis of the ROAD
issues and its resulting specific recommendations. A more complete
description of the way in which these conclusions were reached
would be valuable, and will be included in a later version.
1.3 Overall Plan
In ROAD discussions, it was useful to divide the solution of the IP
scaling problems into short-term, medium-term, and long-term phases
[ROAD]. The real situation is much more complicated, with
considerable overlap as well as uncertainty about time frames, yet
this is a useful model for planning. We support the ROAD group
model that IPv7 belongs to the mid-term time frame, in the sense
that:
(1) more immediate steps must be taken to avoid exhaustion of the
address space before IPv7 can be deployed; and
(2) there are substantial research questions which must be
pursued, but which cannot be expected to be resolved until
after IPv7 is deployed.
For the short-term effort, we support the ROAD group suggestion of
CIDR (Classless Inter-domain Routing) [CIDR], a form of "super-
netting". CIDR will provide short-term relief from exhaustion of
the address space by breaking the rigidly fixed boundaries that
define class A, B, and C IP addresses, using a more flexible bit-
level mask (or equivalently a variable-length address prefix) to
distinguish the network number. To attack the routing information
explosion, CIDR will select addresses to match topology, allowing
the aggregation of routes. As we point out later, this aggregation
will carry over to, and indeed is important to the success of,
IPv7.
We do not dwell on CIDR here; there are already several CIDR-
related engineering efforts in progress in the IETF. This memo
emphasizes IPv7. Section 2 introduces a set of requirements that
must be satisfied by any IPv7 architecture, while Section 3
discusses two alternative approaches for realizing IPv7. One
IAB [Page 3]
Internet Draft IP v7 July 1992
approach is based upon encapsulation and the other is based upon
OSI CLNP. Section 4 briefly surveys some of the important research
problems and efforts that are vital to a long-term solution to the
problems posed by a billion-node Internet. Section 5 summarizes
proposed directions and actions for the community.
2. ARCHITECTURAL PRINCIPLES
To guide our work and to help sort out the competing proposals, an
overall set of design principles is needed. It is customary to refer
to such a set of principles as the "architecture". We believe that a
viable IPv7 should obey the following basic principles.
* Architectural simplicity,
* Globally unique addresses,
* Larger address space,
* Distributed address registration,
* Route aggregation,
* Topology independence,
* Extensibility,
* Compatibility, and
* Interoperability.
All of these are discussed in later sections.
This list is in no sense ordered; we believe all of these requirements
to be important. An actual engineering solution will naturally
involve detailed trade-offs among these objectives, but there are no
simple precedence relations among them.
Before discussing these principles, we make a basic philosophical
point: whatever the choice for IPv7, its "change control" must rest
with the IAB/IETF. Despite our desire to eventually converge with
other standards groups, the ability for protocol and architectural
evolution within the IRTF and IETF is absolutely essential to the
continued success of the Internet.
IAB [Page 4]
Internet Draft IP v7 July 1992
2.1. Architectural Simplicity
We believe that the success of the Internet architecture (as
evidenced by the growth problem discussed in this memo) rests on
its simplicity, which should be retained to the extent possible.
As an example of simplicity, we would prefer an architecture that
does not introduce any new logical boundaries into the Internet.
Such boundaries could make the job of address registration and
route aggregation harder.
2.2. Globally-Unique Addresses
We believe that an important characteristic of the Internet
architecture is the availability of "globally unique" addresses.
The alternative would be to allocate temporary local addresses
dynamically through an address translation scheme, relying upon
directory or name service to map these addresses.
Globally-unique addresses permeate the design of many applications.
For example,
(1) Globally-unique addresses are passed by applications like FTP
to identify third parties.
(2) Globally-unique addresses are very useful for a number of
security schemes.
(3) Globally-unique addresses are important for system management
of the global Internet.
The lack of a globally-unique address would break a number of
applications, impose severe boundary problems in the network, and
make security more difficult. In addition, the directory mechanism
itself would introduce substantial new security risks. It would
also require much more robust and closely-managed servers, speedily
updated, than we have in today's DNS.
A consequence of globally-unique addresses is that when the IPv4
address space becomes totally exhausted, "old" hosts (those which
speak only IPv4) will be unable to communicate with some "new"
hosts. We are prepared to accept this, in the belief that
continuing evolution is a necessary and desirable property of the
Internet, and that we will be able to provide a more-than-
reasonable period for conversion to IPv7 by all hosts. In the
asymptotic situation, application-level gateways can be used to
provide continued connectivity (with reduced functionality) for old
hosts.
IAB [Page 5]
Internet Draft IP v7 July 1992
2.3. Larger Address Space
Since we require globally unique addresses and since the current
address space is too small, we must escape the limitations imposed
by the current 32-bit addresses. The new architecture must allow
much wider address fields, to accommodate:
(1) registering several millions, or even billions, of networks;
(2) allowing some degree of inefficiency in the address
registration;
(3) permitting the expression of a hierarchy in the address;
(4) allowing for new addressing architectures in the future, if
the need arises.
Here (2) and (3) are needed in order to allow decentralized
registration and route aggregation (see Sections 2.4 and 2.5).
This move to a new address format is likely to impact much host and
router software; every piece of software that handles an Internet
address will have to be modified to handle wider addresses. It is
important to note the nature of this impact: broad (many modules
affected) but shallow (very specific, localized changes).
We furthermore argue in favor of a variable-length address format,
with a known upper bound. This upper bound will need to be large,
potentially increasing the IP header size significantly. However,
with a reasonable address assignment scheme, most networks numbers
will be much smaller. Indeed, it might be desirable to use the
existing 4-byte IP addresses for many hosts during a transition.
2.4. Distributed Address Registration
As the Internet becomes more and more international, it is no
longer appropriate to centralize all address registration in one
country. The new IP architecture must allow a decentralized
address registration scheme, for example by means of a multi-layer
hierarchical structure [RFC-1174]. Furthermore, decentralized
registration will be required even within single countries, as the
scale of the Internet increases.
Another important requirement is the capability to embed the
existing IP addresses into the new address space. This will avoid
separate old and new routing tables for IP, and it will prevent
network administrators having to form a huge queue in front of the
new registration agencies during the transition to IPv7.
IAB [Page 6]
Internet Draft IP v7 July 1992
2.5. Route Aggregation
Current IP addresses have three components: a "network number", an
optional "subnet" number, and a "host" number. Networks are
logically grouped into autonomous domains, but the space of network
numbers is flat, without any internal structure. This flat
addressing space leads to routing tables and routing updates that
grow nearly linearly with the total number of networks in the
Internet. Thus, adding a new network has a cost for all the
routers.
It may be objected that, in practice, many routing tables grow much
more slowly than linearly with the number of networks because of
the use of default routes. While this is true, the use of defaults
implies careful route engineering. Such engineering is the norm in
the Internet today, but growth is making it increasingly difficult.
For example, adding a second link to a stub Autonomous Systems will
result in its networks being announced on two entry points instead
of one, and this will require far distant parts of the Internet to
administratively decide which path to use. Soon, such planning
will become impossible. Another drawback of defaults is that they
restrict the amount of implicit policy routing that can be
achieved. Finally, there will always be a core of border routers
that must know all destinations, and whose tables must grow
linearly with the number of networks in the Internet.
To solve this problem, the Internet must aggregate routes, i.e.,
allow one routing table entry to define the next hop for a group of
networks. This requires some structure in the addresses. When all
networks belonging to the same "routing domain" share addresses
whose most significant bits are the same, we can represent this
group of networks by a single entry in the routing tables.
Moreover, this aggregation scheme can be used hierarchically, so
that, for example, all networks in the Hawaiian archipelago may
appear as a single group to the Internet, and all networks of the
island of Oahu as a single group in the archipelago
[Kleinrock&Kamoun]
2.6. Topology Independence
We believe that an important long-term objective is to free the
assignment of addresses from dependence upon the routing topology,
just as domain names are assigned independently of network
connectivity. Managing the allocation of the address space to
match the topology will be an administrative nightmare (which
unfortunately we cannot avoid in the short- and medium-term).
There should be a level of indirection between addressing (naming)
IAB [Page 7]
Internet Draft IP v7 July 1992
a destination and routing to it. This would allow addresses to
have a hierarchical structure determined purely by the
administrative decentralization of address assignment. A directory
service lookup of some sort would be necessary to map these
topology-free names into routes. This lookup would need to be
performed by routers in the forwarding path, but it could be
partially circumvented with route cacheing. Such a scheme would
result in the cost of a new network being felt primarily by those
routers that are actually trying to reach it.
It is clear that such an indirection scheme with route cacheing is
a hard problem, and at present it must be the subject of research.
Until that research is completed, we will have to accept some
topological constraints on addressing and routing. General "policy
routing" is another research topic that is not ready for
engineering at this time. Further research on these topics is
essential, as discussed in Section 4.
2.7. Extensibility
Evolution from IPv4 to IPv7 will be occurring at the same time that
research work is on the verge of requiring architectural extensions
in other areas. Two important examples are supporting real time
applications (e.g., packet voice and video) [Realtime], and
providing better security services. IPv7 should provide easy
extensibility in order to support such new areas.
In particular, it is vital to escape the 60 byte limit on the IPv4
header, in order to have more space available for options.
2.8. Compatibility
As mentioned above, larger addresses should by no means imply a
change in the overall Internet architecture. In particular, it
should certainly not imply a reduction in the network
functionality. For example, it is mandatory that IPv7 should
continue to support the IP multicast architecture. Also, the
current techniques for debugging (e.g., "ping" and "traceroute")
should still be possible.
There are many "tendrils" from IPv4 that reach up into the
transport and application layers [RFC-1122]. Examples are the
receipt of ICMP Unreachable, Redirect, and Source Quench messages,
and setting TOS and TTL values and/or source routes. Other
examples arise in the use of Internet addresses by applications,
e.g., IP. We would ideally like to minimize the impact on the
layers above IP, although this may not prove entirely feasible.
IAB [Page 8]
Internet Draft IP v7 July 1992
2.9. Interoperability
Transition from IPv4 to IPv7 must occupy a number of years, so it
will be necessary for IPv4 hosts to be able to interoperate with
IPv7 hosts. A general scheme for handling old/new host
interoperability, based upon the DNS, is given in [TUBA].
In order to ease the transition and ensure connectivity within the
Internet, the addressing plan should allow the address space to be
*embedded* into the IPv7 space. For example, this will avoid the
need to maintain parallel routing tables.
The following diagram shows the protocol stack that a host may
expect to implement. During the transition to IPv7 (which is
likely to be lengthy), an Internet host must support both IPv4 and
IPv7. It would use IPv4 for communication with an unmodified host
[TUBA].
_________________________________
| |
| |
| TCP/UDP |
| |
|_________________________________|
| | |
| | |
| IPv4 | IPv7 |
| | |
|_______________|_________________|
3. POSSIBLE APPROACHES TO IPv7
Two divergent approaches have been suggested for IPv7.
(1) Some form of IP encapsulation. A good example of this approach
is the IP Address Encapsulation proposal [IPAE].
Encapsulation schemes maximize Internet-layer protocol
compatibility by design; however, these schemes also represent a
significant change in the IP architecture.
(2) Keep the IP architecture essentially unchanged, but change the
format of an IP header to expand the addresses.
A solution based on the existing CLNP protocol is a recent
candidate for the expanded header format [TUBA]. CLNP can be
IAB [Page 9]
Internet Draft IP v7 July 1992
regarded as a revision of IP to fit into the OSI framework,
following the IP architecture without much added functionality.
The primary technical difference between IPv4 and CLNP is the
latter's much wider address fields, variable length up to 20
bytes.
After consideration of the principles of Section 2, the IAB favors the
second class of solutions, and in particular, basing IPv7 on CLNP. It
is important to understand exactly what we mean by basing IPv7 on
CLNP; the rest of this section is therefore devoted to expanding on
this topic.
The IAB proposal is to adopt the CLNP protocol specification and
packet formats for IPv7. The eventual consequence of this decision
will be the publication, at some point in the future, of a complete
IPv7 specification that is functionally and syntactically compatible
with CLNP (defined by the second edition of the ISO 8473 standard,
published in 1992). The intent is to run the existing and future
Internet transport protocols -- in particular, TCP and UDP -- above
IPv7. This would let us benefit from the larger addresses of CLNP
while maintaining the present Internet architecture, without inventing
a new protocol specification and without losing change control. We
must of course avoid gratuitous changes, but the IAB/IETF must be able
to make any changes that are necessary for successful deployment,
operation, and evolution of IPv7. In the longer term, the use of CLNP
will contribute to the inevitable convergence of the OSI and TCP/IP
protocol suites in the Internet (IAB/IETF) context.
The next section reviews the advantages of this CLNP-based solution.
Section 3.2.discusses the issues that must be resolved before a CLNP-
based IPv7 can be deployed in the Interne.
3.1. The case for (and against) CLNP
An advantage of CLNP is simply that the protocol is already
specified, and several implementations exist. Adopting (and
adapting; see the next section) the CLNP format will avoid design
of a new protocol from scratch, a process that would consume
valuable time and delay testing and deployment.
Besides the change to variable-length 20 bytes addresses, CLNP has
another important technical advantage: it frees us from the 60-byte
limitation on an IP header. CLNP has a limit of 254, and there is
an escape code (length 255) that could allow an extended header;
this will allow more extensive use of IP options for future
extensions.
We should admit frankly some technical limitations of CLNP, which
IAB [Page 10]
Internet Draft IP v7 July 1992
it shares with IPv4:
* Maximum packet length is limited to 64K bytes.
* The message identifier uses a 16-bit field.
* The Time-to-live field is one byte.
* If full-size (20 byte) addresses are used in options, the 255
byte limit gets used up fast. For example, the largest source
route with 20-byte addresses will be 8 hops.
In addition, CLNP has awkward boundary alignments for RISC-
architecture machines. We do not regard any of these as show-
stoppers.
3.2 Additional Issues with CLNP.
To adopt the CNLP format for IPv7, a number of issues must be
resolved. Callon has provided one analysis of the changes needed
and the interoperability issues for using CLNP as the basis for
IPv7 [TUBA].
* Address Format and Registration Plan
The existing NSAP registration plans [OSI-NSAP], which were
designed for OSI usage, will have to be reviewed in light of
the Internet needs. One requirement is to embed the existing
Internet addresses.
* Protocol Identification
A substitute for the IPv4 "protocol identification" field will
have to be defined. A plausible solution would be to use the
"last address byte" (the "NSEL" or "NSAP selector" field,
which is defined to be the last byte of the NSAP address by
ANSI standard X3.210-1992).
* Transport Pseudo-Header
The transport protocols TCP and UDP currently include in their
checksums a "pseudo-header" constructed out of the address and
length fields abstracted from the IP header. A suitable
modification to the pseudo-header will have to be designed (or
the pseudo-header dropped from TCP and UDP). This problem is
well-described in [TUBA].
* Layer Interactions
IAB [Page 11]
Internet Draft IP v7 July 1992
The impact upon all the other layers will have to be worked
out in detail.
* Error Reporting
Most important is the reporting of errors from the IP layer.
It might be that the most effective and economical solution
will be to continue to use ICMP with IPv7. Otherwise, it will
be necessary to modify the error-handling strategy of existing
transport protocols to use the OSI error reporting mechanism.
* Address Resolution
A related issue is whether to continue to use ARP for address
resolution on broadcast networks, or whether to adopt the OSI
ES-IS protocol [ES-IS], which essentially combines ICMP and
ARP functions.
* Domain Name Lookups
It will be necessary to modify the DNS to return the new wide
addresses. This problem is well described in [TUBA].
* Header Size
The possible problems posed by increasing the size of the IP
header will have to be evaluated. The impact on slow Internet
links may be alleviated by adapting header compression
algorithms analogous to Jacobson's [RFC-1144].
* Multicasting
The proposed extensions to CLNP for multicasting will have to
be incorporated.
In general, a very careful review will be required to quickly
locate the potential problems and to cure them. In line with the
Internet tradition of "learning from experience", this will need
early experiments, which will have to be taken into account in the
transition timing.
Note that the IPv7 implementation may differ from the OSI CLNP
implementation by having a different "service" interface to the
transport layer. That is, IPv7 implementors may choose to minimize
changes on the transport side of the interface [RFC-1122]. Thus, a
host that supports both the Internet and the OSI stacks may have
the following protocol stacks:
IAB [Page 12]
Internet Draft IP v7 July 1992
________________ _________________________________
| || |
| || |
| TP4 || TCP/UDP |
| || |
|________________||_________________________________|
| || | |
| || | |
| OSI CLNP || IPv4 | IPv7 |
| || | |
|________________||_______________|_________________|
It is of course a long-term objective to work towards a single
unified internet protocol layer for the entire Internet.
In the OSI framework, IS-IS and IDRP are the currently-defined IGP
and EGP routing protocols, respectively. A careful study may be
needed to evaluate whether to adopt ISO routing protocols or to
evolve IP routing protocols to support IPV7. The routing protocols
currently in use in the Internet represent a huge investment that
should be thrown away only for compelling reasons. Furthermore, we
must facilitate further research in routing protocols.
In order to survive the transition to IPv7, the existing routing
protocols will have to be upgraded to handle long variable-length
addresses and masks/prefixes. The careful study of routing
protocols is an important element in the success of the migration.
4. RESEARCH AREAS
A number of long-term approaches have been suggested for major
advances in Internet routing. These include IDPR, NIMROD, and PIP.
We urge that these ideas be aggressively researched.
Section 2.5 exhibited weak points of the current Internet architecture
and routing technology. Extending the number of connected networks or
the number of Internet links causes additional cost for all (or at
least many) Internet routers. Ideally, the cost would be borne only
by those who intend to engage in exchanges with the new networks or
over the new links. Furthermore, the assignment of addresses is tied
to the topology, to allow route aggregation.
Removing these constraints requires the development of an indirection
and route cacheing mechanism. This is very important for the future,
but it is definitely a research project. One definition of research
is "a project which is allowed to fail", and indeed it is a matter of
conjecture that a route lookup mechanism can be designed with
IAB [Page 13]
Internet Draft IP v7 July 1992
sufficient speed and robustness to satisfy the requirements. Research
in this area should be a critical task for the long-term evolution of
Internet routing.
General policy-based routing is another issue that we regard as a
research topic, for the long term.
5. THE WAY FORWARD
In order to guarantee the survival of the Internet, work should start
now on the various items detailed in this document. Delaying by a few
more months in order to gather more information would be very unlikely
to help us make a decision, and would encourage people to spend their
time crafting arguments for why CLNP is or is not a better solution
than some alternative, rather than working on the detailed
specification of how CLNP can be used as the basis for IPv7 and
resolving the technical questions (particularly in the area of address
administration and the effect on existing application software) that
must be answered in order to specify a deployment plan for IPv7.
We therefore recommend:
1. An immediate IETF effort to engineer CIDR, including the
extensions to the inter-AD routing protocols to allow
masks/prefixes, and the associated address administration
paradigm. The latter is critical to the success of CIDR.
The routing information explosion is upon us now. Already, some
pockets of the Internet are showing restricted connectivity due
to routing table overflow. With the rapid pace of Internet
growth, the problem has to be addressed immediately, even before
introducing IPv7 and its large addresses. We urge that route
aggregation be incorporated as soon as possible, using the CIDR
scheme.
2. An immediate IETF effort to prepare a detailed technical and
organizational plan for using CLNP as the basis for IPv7.
The IAB favors CLNP, which retains the general Internet
architecture and its principles unchanged while changing the IP
packet format to accommodate wider addresses.
3. That the long-term research discussed in Section 4 be continued
and encouraged.
It is important to observe that CIDR uses 32 bit addresses with the L
first bits used for routing. Here L is determined distinctly for each
routing table entry. Projecting this onto IPv7, we see that IPv7 will
IAB [Page 14]
Internet Draft IP v7 July 1992
use X bit addresses with the L first bits used for routing, where X is
to be determined. Thus, we see that CIDR is a natural step along the
route to IPv7, and a step that needs to be started as soon as
possible.
REFERENCES
[CIDR] Fuller, V., Li, T., and J. Yu, "Supernetting: an Address
Assignment and Aggregation Strategy", RFC in preparation, April
10, 1992.
[CLNP] "Protocol for Providing the Connectionless-Mode Network
Service", ISO 8473, 1988.
[ES-IS] "End-System to Intermediate System Routing Exchange Protocol
for use in Conjunction with the Protocol for the Provision of the
Connectionless-mode Network Service", ISO 9542, 1987.
[IEN-005] Cerf, V., "TCP Version 2 Specification", Internet Experiment
Note IEN-005, March 1977.
[IPAE] Hinden, R. and D. Crocker, "A Proposal for IP Address
Encapsulation (IPAE): A Compatible Version of IP with Large
Addresses", RFC in preparation.
[Kleinrock&Kamoun] Kleinrock, L. and K. Kamoun, "Hierarchical Routing
for Large Networks: Performance Evaluation and Optimization",
Computer Networks, 1, 155-174, 1977.
[OSI-NSAP] Collella, R., Gardner, E., and R. Callon, "Guidelines for
OSI NSAP Allocation in the Internet", RFC-1237, July 1991.
[RFC-1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers", RFC-1122, October 1989.
[RFC-1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC-1144, February 1990.
IAB [Page 15]
Internet Draft IP v7 July 1992
[RFC-1174] Cerf, V., "IAB Recommended Policy on Distributing Internet
Identifier Assignment", RFC-1174, August 1990.
[Realtime] Braden, R., "Integrated Service in the Internet
Architecture", High-Performance Network Research Report, ISI,
October 1991.
[ROAD] "The Internet Routing and Addressing Task Force: Summary
Report", Brim, S. and P. Ford, Working Draft, 23 June 1992.
[TUBA] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), a Simple
Proposal for Internet Addressing and Routing", RFC-1347, June
1992.
Security Considerations
Support for privacy and security is fundamental to the architectural
choice of globally unique addresses, as noted in Section 2.2.
Author's Address
Internet Architecture Board
c/o Robert Braden, IAB Executive Director
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
Phone: 310-822-1511
Fax: 310-823-6714
Email: Braden@ISI.EDU
IAB [Page 16]
