Skip to main content

Technical Criteria for Choosing IP The Next Generation (IPng)

The information below is for an old version of the document that is already published as an RFC.
Document Type This is an older version of an Internet-Draft that was ultimately published as an RFC.
Authors Frank Kastenholz , Dr. Craig Partridge
Last updated 2013-03-02 (Latest revision 2002-06-25)
Stream Legacy stream
Stream Legacy state (None)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1726 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to (None)

     Technical Criteria for Choosing
      IP:The Next Generation (IPng)


               25 May 1994

             Frank Kastenholz
            FTP Software, Inc
              2 High Street
    North Andover, Mass 01845-2620 USA


             Craig Partridge
       BBN Systems and Technologies

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

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

Internet Draft      IPng Technical Criteria           May 1994

To learn the current status of any Internet-Draft, please
check the 1id-abstractis.txt listing contained in the
Internet-Drafts Shadow Directories on,,, or

This is a working document only, it should neither be cited
nor quoted in any formal document.

This document will expire before 30 Nov. 1994.

Distribution of this document is unlimited.

Please send comments to the authors.

Partridge & Kastenholz Exp. 30 Nov. 1994              [Page 1]

Internet Draft      IPng Technical Criteria           May 1994

1.  Introduction

This memo presents a set of criteria that the authors' believe
should be used to help evaluate protocols being proposed for
adoption as the next generation of IP.  The criteria presented
here were culled from several sources, including "IP Version
7" [1], "IESG Deliberations on Routing and Addressing" [2],
"Towards the Future Internet Architecture" [3], the IPng
Requirements BOF held at the Washington D.C. IETF Meeting in
December of 1992, the IPng Working Group meeting at the
Seattle IETF meeting in March 1994, and the discussions held
on the Big-Internet mailing list (,
send requests to join to
and the mailing lists devoted to the individual IPng efforts.

This document presumes that a new IP-layer protocol is
actually desired. There is some discussion in the community as
to whether we can extend the life of IPv4 for a significant
amount of time by better engineering of, e.g., routing
protocols, or we should develop IPng now.  This question is
not addressed in this document.

We would like to gratefully acknowledge the assistance of
literally hundreds of people who shared their views and
insights with us.  However, this memo is solely the personal
opinion of the authors and in no way represents, nor should it
be construed as representing, the opinion of the ISOC, the
IAB, the IRTF, the IESG, the IETF, the Internet community as a
whole, nor the authors' respective employers.

Partridge & Kastenholz Exp. 30 Nov. 1994              [Page 2]

Internet Draft      IPng Technical Criteria           May 1994

2.  Goals

We believe that by developing a list of criteria for
evaluating proposals for IP:The Next Generation (IPng), the
IETF will make it easier for developers of proposals to
prioritize their work and efforts and make reasoned choices as
to where they should spend relatively more and less time.
Furthermore, a list of criteria may help the IETF community
determine which proposals are serious contenders for a next
generation IP, and which proposals are insufficient to the
task.  Note that these criteria are probably not sufficient to
make final decisions about which proposal is best.  Questions
such as whether to trade a little performance (e.g., packets
per second routed) for slightly more functionality (e.g., more
flexible routing) cannot be easily addressed by a simple list
of criteria.  However, at minimum, we believe that protocols
that meet these criteria are capable of serving as the future

This set of criteria originally began as an ordered list, with
the goal of ranking the importance of various criteria.
Eventually, the layout evolved into the current form, where
each criterion was presented without weighting, but a time
frame, indicating approximately when a specific criterion, or
feature of a criterion, should be available was added to the

We have attempted to state the criteria in the form of goals
or requirements and not demand specific engineering solutions.
For example, there has been talk in the community of making
route aggregation a requirement.  We believe that route
aggregation is not, in and of itself, a requirement but rather
one part of a solution to the real problem of scaling to some
very large, complex topology. Therefore, route aggregation is
NOT listed as a requirement; instead, the more general
functional goal of having the routing scale is listed instead
of the particular mechanism of route aggregation.

In determining the relative timing of the various criteria, we
have had two guiding principles.  First, IPng must offer an
internetwork service akin to that of IPv4, but improved to
handle the well-known and widely-understood problems of
scaling the Internet architecture to more end-points and an
ever increasing range of bandwidths.  Second, it must be
desirable for users and network managers to upgrade their

Partridge & Kastenholz Exp. 30 Nov. 1994              [Page 3]

Internet Draft      IPng Technical Criteria           May 1994

equipment to support IPng.  At a minimum, this second point
implies that there must be a straightforward way to transition
systems from IPv4 to IPng.  But it also strongly suggests that
IPng should offer features that IPv4 does not; new features
provide a motivation to deploy IPng more quickly.

Partridge & Kastenholz Exp. 30 Nov. 1994              [Page 4]

Internet Draft      IPng Technical Criteria           May 1994

3.  Note on Terminology

The existing proposals tend distinguish between end-point
identification of, e.g., individual hosts, and topological
addresses of network attachment points.  In this memo we do
not make that distinction. We use the term "address" as it is
currently used in IPv4; i.e., for both the identification of a
particular endpoint or host AND as the topological address of
a point on the network. We presume that if the endpoint/
address split remains, the proposals will make the proper
distinctions with respect to the criteria enumerated below.

Partridge & Kastenholz Exp. 30 Nov. 1994              [Page 5]

Internet Draft      IPng Technical Criteria           May 1994

4.  General Principles

4.1.  Architectural Simplicity

    In anything at all, perfection is finally attained not
    when  there  is  no  longer  anything to add, but when
    there is no longer anything to take away.

Antoine de Saint-Exupery

We believe that many communications functions are more
appropriately performed at protocol layers other than the IP
layer.  We see protocol stacks as hourglass-shaped, with IPng
in the middle, or waist, of the hourglass.  As such,
essentially all higher-layer protocols make use of and rely
upon IPng.  Similarly IPng, by virtue of its position in the
"protocol hourglass" encompasses a wide variety of lower-layer
protocols.  When IPng does not perform a particular function
or provide a certain service, it should not get in the way of
the other elements of the protocol stack which may well wish
to perform the function.

4.2.  One Protocol to Bind Them All

One of the most important aspects of The Internet is that it
provides global IP-layer connectivity. The IP layer provides
the point of commonality among all of the nodes on the
Internet. In effect, the main goal of the Internet is to
provide an IP Connectivity Service to all who wish it.

This does NOT say that the Internet is a One-Protocol
Internet. The Internet is today, and shall remain in the
future, a Multi-Protocol Internet.  Multi-Protocol operations
are required to allow for continued testing, experimentation,
and development and because service providers' customers
clearly want to be able to run protocols such as CLNP, DECNET,
and Novell over their Internet connections.

4.3.  Live Long

It is very difficult to change a protocol as central to the
workings of the Internet as IP. Even more problematic is
changing such a protocol frequently.  This simply can not be

Partridge & Kastenholz Exp. 30 Nov. 1994              [Page 6]

Internet Draft      IPng Technical Criteria           May 1994

done. We believe that it is impossible to expect the community
to make significant, non-backward compatible changes to the IP
layer more often than once every 10-15 years. In order to be
conservative, we strongly urge protocol developers to consider
what the Internet will look like in 20 years and design their
protocols to fit that vision.

As a data point, the SNMP community has had great difficulty
moving from SNMPv1 to SNMPv2.  Frequent changes in software
are hard.

4.4.  Live Long AND Prosper

We believe that simply allowing for bigger addresses and more
efficient routing is not enough of a benefit to encourage
vendors, service providers, and users to switch to IPng, with
its attendant disruptions of service, etc.  These problems can
be solved much more simply with faster routers, balkanization
of the Internet address space, and other hacks.

We believe that there must be positive functional or
operational benefits to switching to IPng.

In other words, IPng must be able to live for a long time AND
it must allow the Internet to prosper and to grow to serve new
applications and user needs.

4.5.  Co-operative Anarchy

A major contributor to the Internet's success is the fact that
there is no single, centralized, point of control or
promulgator of policy for the entire network.  This allows
individual constituents of the network to tailor their own
networks, environments, and policies to suit their own needs.
The individual constituents must cooperate only to the degree
necessary to ensure that they interoperate.

We believe that this decentralized and decoupled nature of the
Internet must be preserved.  Only a minimum amount of
centralization or forced cooperation will be tolerated by the
community as a whole.

We also believe that there are some tangible benefits to this

Partridge & Kastenholz Exp. 30 Nov. 1994              [Page 7]

Internet Draft      IPng Technical Criteria           May 1994

decoupled nature. For example,

-    It is easier to experiment with new protocols and
     services and then roll out intermediate and final results
     in a controlled fashion.

-    By eliminating a single point of control, a single point
     of failure is also eliminated, making it much less likely
     that the entire network will fail.

-    It allows the administrative tasks for the network to be
     more widely distributed.

An example of the benefits of this "Cooperative Anarchy" can
be seen in the benefits derived from using the Domain Naming
System over the original HOSTS.TXT system.

Partridge & Kastenholz Exp. 30 Nov. 1994              [Page 8]

Internet Draft      IPng Technical Criteria           May 1994

5.  Criteria

This section enumerates the criteria against which we suggest
the IP:The Next Generation proposals be evaluated.

Each criterion is presented in its own section. The first
paragraph of each section is a short, one or two sentence
statement of the criterion.  Additional paragraphs then
explain the criterion in more detail, clarify what it does and
does not say and provide some indication of its relative

Also, each criterion includes a subsection called "Time
Frame".  This is intended to give a rough indication of when
the authors believe that the particular criterion will become
"important".  We believe that if an element of technology is
significant enough to include in this document then we
probably understand the technology enough to predict how
important that technology will be.  In general, these time
frames indicate that, within the desired time frame, we should
be able to get an understanding of how the feature will be
added to a protocol, perhaps after discussions with the
engineers doing the development.  Time Frame is not a
deployment schedule since deployment schedules depend on non-
technical issues, such as vendors determining whether a market
exists, users fitting new releases into their systems, and so

5.1.  Scale

     The IPng Protocol must scale to allow the identification
     and addressing of at least 10**12 end systems (and
     preferably much more).  The IPng Protocol, and its
     associated routing protocols and architecture must allow
     for at least 10**9 individual networks (and preferably
     more).  The routing schemes must scale at a rate that is
     less than the square root of the number of constituent

     The initial, motivating, purpose of the IPng effort is to
     allow the Internet to grow beyond the size constraints
     imposed by the current IPv4 addressing and routing

Partridge & Kastenholz Exp. 30 Nov. 1994              [Page 9]

Internet Draft      IPng Technical Criteria           May 1994


     Both aspects of scaling are important.  If we can't route
     then connecting all these hosts is worthless, but without
     connected hosts, there's no point in routing, so we must
     scale in both directions.

     In any proposal, particular attention must be paid to
     describing the routing hierarchy, how the routing and
     addressing will be organized, how different layers of the
     routing interact, and the relationship between addressing
     and routing.

     Particular attention must be paid to describing what
     happens when the size of the network approaches these
     limits. How are network, forwarding, and routing
     performance affected? Does performance fall off or does
     the network simply stop as the limit is neared.

     This criterion is the essential problem motivating the
     transition to IPng.  If the proposed protocol does not
     satisfy this criteria, there is no point in considering

     We note that one of the white papers solicited for the
     IPng process [5] indicates that 10**12 end nodes is a
     reasonable estimate based on the expected number of homes
     in the world and adding two orders of magnitude for
     "safety".  However, this white paper treats each home in
     the world as an end-node of a world-wide Internet.  We
     believe that each home in the world will in fact be a
     network of the world-wide Internet.  Therefore, if we
     take [5]'s derivation of 10**12 as accurate, and change
     their assumption that a home will be an end-node to a
     home being a network, we may expect that there will be
     the need to support at least 10**12 networks, with the
     possibility of supporting up to 10**15 end-nodes.

Time Frame
     Any IPng proposal should be able to show immediately that
     it has an architecture for the needed routing protocols,
     addressing schemes, abstraction techniques, algorithms,
     data structures, and so on that can support growth to the
     required scales.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 10]

Internet Draft      IPng Technical Criteria           May 1994

     Actual development, specification, and deployment of the
     needed protocols can be deferred until IPng deployment
     has extended far enough to require such protocols.  A
     proposed IPng should be able to demonstrate ahead of time
     that it can scale as needed.

5.2.  Topological Flexibility

     The routing architecture and protocols of IPng must allow
     for many different network topologies.  The routing
     architecture and protocols must not assume that the
     network's physical structure is a tree.

     As the Internet becomes ever more global and ubiquitous,
     it will develop new and different topologies. We already
     see cases where the network hierarchy is very "broad"
     with many subnetworks, each with only a few hosts and
     where it is very "narrow", with few subnetworks each with
     many hosts.  We can expect these and other topological
     forms in the future.  Furthermore, since we expect that
     IPng will allow for many more levels of hierarchy than
     are allowed under IPv4, we can expect very "tall" and
     very "short" topologies as well.

     Constituent organizations of the Internet should be
     allowed to structure their internal topologies in any
     manner they see fit.  Within reasonable implementation
     limits, organizations should be allowed to structure
     their addressing in any manner.  We specifically wish to
     point out that if the network's topology or addressing is
     hierarchical, constituent organizations should be able to
     allocate to themselves as many levels of hierarchy as
     they wish.

     It is very possible that the diameter of the Internet
     will grow to be extremely large; perhaps larger than 256

     Neither the current, nor the future, Internet will be
     physically structured as a tree, nor can we assume that
     connectivity can occur only between certain points in the
     graph.  The routing and addressing architectures must

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 11]

Internet Draft      IPng Technical Criteria           May 1994

     allow for multiply connected networks and be able to
     utilize multiple paths for any reason, including
     redundancy, load sharing, type- and quality-of-service

Time Frame
     We believe that Topological Flexibility is an inherent
     element of a protocol and therefore should be immediately
     demonstrable in an IPng proposal.

5.3.  Performance

     A state of the art, commercial grade router must be able
     to process and forward IPng traffic at speeds capable of
     fully utilizing common, commercially available, high-
     speed media at the time.  Furthermore, at a minimum, a
     host must be able to achieve data transfer rates with
     IPng comparable to the rates achieved with IPv4, using
     similar levels of host resources.

     Network media speeds are constantly increasing.  It is
     essential that the Internet's switching elements
     (routers) be able to keep up with the media speeds.

     We limit this requirement to commercially available
     routers and media.  If some network site can obtain a
     particular media technology "off the shelf", then it
     should also be able to obtain the needed routing
     technology "off the shelf."  One can always go into some
     laboratory or research center and find newer, faster,
     technologies for network media and for routing.  We do
     believe, however, that IPng should be routable at a speed
     sufficient to fully utilize the fastest available media,
     though that might require specially built, custom,

     We expect that more and more services will be available
     over the Internet. It is not unreasonable, therefore, to
     expect that the ratio of "local" traffic (i.e. the
     traffic that stays on one's local network) to "export"
     traffic (i.e. traffic destined to or sourced from a
     network other than one's own local network) will change,

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 12]

Internet Draft      IPng Technical Criteria           May 1994

     and the percent of export traffic will increase.

     We note that the host performance requirement should not
     be taken to imply that IPng need only be as good as IPv4.
     If an IPng candidate can achieve better performance with
     equivalent resources (or equivalent transfer rates with
     fewer resources) vis-a-vis IPv4 then so much the better.
     We also observe that many researchers believe that a
     proper IPng router should be capable of routing IPng
     traffic over links at speeds that are capable of fully
     utilizing an ATM switch on the link.

     Some developments indicate that the use of very high
     speed point-to-point connections may become commonplace.
     In particular, [5] indicates that OC-3 speeds may be
     widely used in the Cable TV Industry and there may be
     many OC-3 speed lines connecting to central switching

     Processing of the IPng header, and subsequent headers
     (such as the transport header), can be made more
     efficient by aligning fields on their natural boundaries
     and making header lengths integral multiples of typical
     word lengths (32, 64, and 128 bits have been suggested)
     in order to preserve alignment in following headers.

     We point out that optimizing the header's fields and
     lengths only to today's processors may not be sufficient
     for the long term.  Processor word and cache-line
     lengths, and memory widths are constantly increasing.  In
     doing header optimizations, the designer should predict
     word-widths one or two CPU generations into the future
     and optimize accordingly.  If IPv4 and TCP had been
     optimized for processors common when they were designed,
     they would be very efficient for 6502s and Z-80s.

Time Frame
     An IPng proposal must provide a plausible argument of how
     it will scale up in performance.  (Obviously no one can
     completely predict the future, but the idea is to
     illustrate that if technology trends in processor
     performance and memory performance continue, and perhaps
     using techniques like parallelism, there is reason to
     believe the proposed IPng will scale as technology

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 13]

Internet Draft      IPng Technical Criteria           May 1994

5.4.  Robust Service

     The network service and its associated routing and
     control protocols must be robust.

     Murphy's Law applies to networking.  Any proposed IPng
     protocol must be well-behaved in the face of malformed
     packets, mis-information, and occasional failures of
     links, routers and hosts.  IPng should perform gracefully
     in response to willful management and configuration
     mistakes (i.e. service outages should be minimized).

     Putting this requirement another way, IPng must make it
     possible to continue the Internet tradition of being
     conservative in what is sent, but liberal in what one is
     willing to receive.

     We note that IPv4 is reasonably robust and any proposed
     IPng must be at least as robust as IPv4.

     Hostile attacks on the network layer and Byzantine
     failure modes must be dealt with in a safe and graceful

     We note that Robust Service is, in some form, a part of
     security and vice-versa.

     The detrimental effects of failures, errors, buggy
     implementations, and misconfigurations must be localized
     as much as possible.  For example, misconfiguring a
     workstation's IP Address should not break the routing
     protocols.  in the event of misconfigurations, IPng must
     to be able to detect and at least warn, if not work
     around, any misconfigurations.

     Due to its size, complexity, decentralized
     administration, error-prone users and administrators, and
     so on, The Internet is a very hostile environment. If a
     protocol can not be used in such a hostile environment
     then it is not suitable for use in the Internet.

     Some predictions have been made that, as the Internet
     grows and as more and more technically less-sophisticated

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 14]

Internet Draft      IPng Technical Criteria           May 1994

     sites get connected, there will be more failures in the
     network.  These failures may be a combination of simple
     size; if the size of the network goes up by a factor of n
     then the total number of failures in the network can be
     expected to increase by some function of n.  Also, as the
     network's users become less sophisticated, it can be
     assumed that they will make more, innocent and well
     meaning, mistakes, either in configuration or use of
     their systems.

     The IPng protocols should be able to continue operating
     in an environment that suffers more, total, outages than
     we are currently used to.  Similarly, the protocols must
     protect the general population from errors (either of
     omission or commission) made by individual users and

Time Frame
     We believe that the elements of Robust Service should be
     available immediately in the protocol with two

     The security aspects of Robust Service are, in fact,
     described elsewhere in this document.

     Protection against Byzantine failure modes is not needed
     immediately.  A proposed architecture for it should be
     done immediately.  Prototype development should be
     completed in 12-18 months, with final deployment as

5.5.  Transition

     The protocol must have a straightforward transition plan
     from the current IPv4.

     A smooth, orderly, transition from IPv4 to IPng is
     needed.  If we can't transition to the new protocol, then
     no matter how wonderful it is, we'll never get to it.

     We believe that it is not possible to have a "flag-day"
     form of transition in which all hosts and routers must

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 15]

Internet Draft      IPng Technical Criteria           May 1994

     change over at once. The size, complexity, and
     distributed administration of the Internet make such a
     cutover impossible.

     Rather, IPng will need to co-exist with IPv4 for some
     period of time.  There are a number of ways to achieve
     this co-existence such as requiring hosts to support two
     stacks, converting between protocols, or using backward
     compatible extensions to IPv4.  Each scheme has its
     strengths and weaknesses, which have to be weighed.

     Furthermore, we note that, in all probability, there will
     be IPv4 hosts on the Internet effectively forever.  IPng
     must provide mechanisms to allow these hosts to
     communicate, even after IPng has become the dominant
     network layer protocol in the Internet.

     The absence of a rational and well-defined transition
     plan is not acceptable.  Indeed, the difficulty of
     running a network that is transitioning from IPv4 to IPng
     must be minimized.  (A good target is that running a
     mixed IPv4-IPng network should be no more and preferably
     less difficult than running IPv4 in parallel with
     existing non-IP protocols).

     Furthermore, a network in transition must still be
     robust.  IPng schemes which maximize stability and
     connectivity in mixed IPv4-IPng networks are preferred.

     Finally, IPng is expected to evolve over time and
     therefore, it must be possible to have multiple versions
     of IPng, some in production use, some in experimental,
     developmental, or evaluation use, to coexist on the
     network.  Transition plans must address this issue.

     The transition plan must address the following general
     areas of the Internet's infrastructure:
     + Host Protocols and Software
     + Router Protocols and Software
     + Security and Authentication
     + Domain Name System
     + Network Management
     + Operations Tools (e.g., Ping and Traceroute)
     + Operations and Administration procedures

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 16]

Internet Draft      IPng Technical Criteria           May 1994

     The impact on protocols which use IP addresses as data
     (e.g. DNS, distributed file systems, SNMP and FTP) must
     be specifically addressed.

     The transition plan should address the issue of cost
     distribution. That is, it should identify what tasks are
     required of the service providers, of the end users, of
     the backbones and so on.

Time Frame
     A transition plan is required immediately.

5.6.  Media Independence

     The protocol must work across an internetwork of many
     different LAN, MAN, and WAN media, with individual link
     speeds ranging from a ones-of-bits per second to hundreds
     of gigabits per second.  Multiple-access and point-to-
     point media must be supported, as must media supporting
     both switched and permanent circuits.

     The joy of IP is that it works over just about anything.
     This generality must be preserved.  The ease of adding
     new technologies, and ability to continue operating with
     old technologies must be maintained.

     We believe this range of speed is right for the next
     twenty years, though we may wish to require terabit
     performance at the high-end.  We believe that, at a
     minimum, media running at 500 gigabits per second will be
     commonly available within 10 years.  The low end of the
     link-speed range is based on the speed of systems like
     pagers and ELF (ELF connects to submerged submarines and
     has a "speed" on the order of <10 characters per second).

     By switched circuits we mean both "permanent" connections
     such as X.25 and Frame Relay services AND "temporary"
     types of dialup connections similar to today's SLIP and
     dialup PPP services, and perhaps, ATM SVCs.  The latter
     form of connection implies that dynamic network access
     (i.e., the ability to unplug a machine, move it to a
     different point on the network topology, and plug it back

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 17]

Internet Draft      IPng Technical Criteria           May 1994

     in, possibly with a changed IPng address) is required. We
     note that this is an aspect of mobility.

     By work, we mean we have hopes that a stream of IPng
     datagrams (whether from one source, or many) can come
     close to filling the link at high speeds, but also scales
     gracefully to low speeds.

     Many network media are multi-protocol.  It is essential
     that IPng be able to peacefully co-exist on such media
     with other protocols.  Routers and hosts must be able to
     discriminate among the protocols that might be present on
     such a medium.  For example, on an Ethernet, a specific,
     IPng Ethernet Type value might be called for; or the old
     IPv4 Ethernet type is used and the first four (version
     number in the old IPv4 header) bits would distinguish
     between IPv4 and IPng.

     Different media have different MAC address formats and
     schemes.  It must be possible for a node to dynamically
     determine the MAC address of a node given that node's IP
     address.  We explicitly prohibit using static, manually
     configured mappings as the standard approach.

     Another aspect of this criterion is that many different
     MTUs will be found in an IPng internetwork.  An IPng must
     be able to operate in such a multi-MTU environment.  It
     must be able to adapt to the MTUs of the physical media
     over which it operates.  Two possible techniques for
     dealing with this are path MTU discovery and
     fragmentation and reassembly; other techniques might
     certainly be developed.

     We note that, as of this writing (mid 1994), ATM seems to
     be set to become a major network media technology.  Any
     IPng should be designed to operate over ATM.  However,
     IPng still must be able to operate over other, more
     "traditional" network media.  Furthermore, a host on an
     ATM network must be able to interoperate with a host on
     another, non-ATM, medium, with no more difficulty or
     complexity than hosts on different media can interoperate
     today using IPv4.

     IPng must be able to deal both with "dumb" media, such as
     we have today, and newer, more intelligent, media.  In

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 18]

Internet Draft      IPng Technical Criteria           May 1994

     particular, IPng functions must be able to exist
     harmoniously with lower-layer realizations of the same,
     or similar, functions. Routing and resource management
     are two areas where designers should pay particular
     attention.  Some subnetwork technologies may include
     integral accounting and billing capabilities, and IPng
     must provide the correct control information to such

Time Frame
     Specifications for current media encapsulations (i.e.,
     all encapsulations that are currently Proposed standards,
     or higher, in the IETF) are required immediately.  These
     specifications must include any auxiliary protocols
     needed (such as an address resolution mechanism for
     Ethernet or the link control protocol for PPP).  A
     general 'guide' should also be available immediately to
     help others develop additional media encapsulations.
     Other, newer, encapsulations can be developed as the need
     becomes apparent.

     Van Jacobson-like header compression should be shown
     immediately, as should any other aspects of very-low-
     speed media.  Similarly, any specific aspects of high-
     speed media should be shown immediately.

5.7.  Unreliable Datagram Service

     The protocol must support an unreliable datagram delivery

     We like IP's datagram service and it seems to work very
     well.  So we must keep it.  In particular, the ability,
     within IPv4, to send an idempotent datagram, without
     prearrangement, is extremely valuable (in fact, may be
     required for some applications such as SNMP) and must be

     Furthermore, the design principle that says that we can
     take any datagram and throw it away with no warning or
     other action, or take any router and turn it off with no
     warning, and have datagram traffic still work, is very

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 19]

Internet Draft      IPng Technical Criteria           May 1994

     powerful.  This vastly enhances the robustness of the
     network and vastly eases administration and maintenance
     of the network.  It also vastly simplifies the design and
     implementation of software.[14]

     Furthermore, the Unreliable Datagram Service should
     support some minimal level of service; something that is
     approximately equivalent to IPv4 service.  This has two
     functions; it eases the task of IPv4/IPng translating
     systems in mapping IPv4 traffic to IPng and vice versa,
     and it simplifies the task of fitting IPng into small,
     limited environments such as boot ROMs.

Time Frame
     Unreliable Datagram Service must be available

5.8.  Configuration, Administration, and Operation

     The protocol must permit easy and largely distributed
     configuration and operation. Automatic configuration of
     hosts and routers is required.

     People complain that IP is hard to manage.  We cannot
     plug and play.  We must fix that problem.

     We do note that fully automated configuration, especially
     for large, complex networks, is still a topic of
     research.  Our concern is mostly for small and medium
     sized, less complex, networks; places where the essential
     knowledge and skills would not be as readily available.

     In dealing with this criterion, address assignment and
     delegation procedures and restrictions should be
     addressed by the proposal.  Furthermore, "ownership" of
     addresses (e.g. user or service provider) has recently
     become a concern and the issue should be addressed.

     We require that a node be able to dynamically obtain all
     of its operational, IP-level parameters at boot time via
     a dynamic configuration mechanism.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 20]

Internet Draft      IPng Technical Criteria           May 1994

     A host must be able to dynamically discover routers on
     the host's local network.  Ideally, the information which
     a host learns via this mechanism would also allow the
     host to make a rational selection of which first-hop
     router to send any given packet to.  IPng must not
     mandate that users or administrators manually configure
     first-hop routers into hosts.

     Also, a strength of IPv4 has been its ability to be used
     on isolated subnets.  IPng hosts must be able to work on
     networks without routers present.

     Additional elements of this criterion are:

   -    Ease of address allocation.

   -    Ease of changing the topology of the network within a
        particular routing domain.

   -    Ease of changing network provider.

   -    Ease of (re)configuring host/endpoint parameters such
        as addressing and identification.

   -    Ease of (re)configuring router parameters such as
        addressing and identification.

   -    Address allocation and assignment authority must be
        delegated as far 'down' the administrative hierarchy
        as possible.

     The requirements of this section apply only to IPng and
     its supporting protocols (such as for routing, address
     resolution, and network-layer control).  Specifically, as
     far as IPng is concerned, we are concerned only with how
     routers and hosts get their configuration information.

     We note that in general, automatic configuration of hosts
     is a large and complex problem and getting the
     configuration information into hosts and routers is only
     one, small, piece of the problem.  A large amount of
     additional, non-Internet-layer work is needed in order to
     be able to do "plug-and-play" networking.  Other aspects
     of "plug-and-play" networking include things like:
     Autoregistration of new nodes with DNS, configuring

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 21]

Internet Draft      IPng Technical Criteria           May 1994

     security service systems (e.g. Kerberos), setting up
     email relays and mail servers, locating network
     resources, adding entries to NFS export files, and so on.
     To a large degree, these capabilities do not have any
     dependence on the IPng protocol (other than, perhaps, the
     format of addresses).

     We require that any IPng proposal not impede or prevent,
     in any way, the development of "plug-and-play" network
     configuration technologies.

     Automatic configuration of network nodes must not prevent
     users or administrators from also being able to manually
     configure their systems.

Time Frame
     A method for plug and play on small subnets is
     immediately required.

     We believe that this is an extremely critical area for
     any IPng as a major complaint of the IP community as a
     whole is the difficulty in administering large IP
     networks.  Furthermore, ease of installation is likely to
     speed the deployment of IPng.

5.9.  Secure Operation

     IPng must provide a secure network layer.

     We need to be sure that we have not created a network
     that is a cracker's playground.

     In order to meet the Robustness criterion, some elements
     of what is commonly shrugged off as "security" are
     needed; e.g. to prevent a villain from injecting bogus
     routing packets, and destroying the routing system within
     the network.  This criterion covers those aspects of
     security that are not needed to provide the Robustness

     Another aspect of security is non-repudiation of origin.
     In order to adequately support the expected need for

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 22]

Internet Draft      IPng Technical Criteria           May 1994

     simple accounting, we believe that this is a necessary

     In order to safely support requirements of the commercial
     world, IPng-level security must have capabilities to
     prevent eavesdroppers from monitoring traffic and
     deducing traffic patterns.  This is particularly
     important in multi-access networks such as cable TV

     Aspects of security at the IP level to be considered

   -    Denial of service protections[6],

   -    Continuity of operations[6],

   -    Precedence and preemption[6],

   -    Ability to allow rule-based access control

   -    Protection of routing and control-protocol

   -    Authentication of routing information exchanges,
        packets, data, and sources (e.g. make sure that the
        routing packet came from a router) [9],

   -    QOS security (i.e., protection against improper use of
        network-layer resources, functions, and capabilities),

   -    Auto-configuration protocol operations in that the
        host must be assured that it is getting its
        information from proper sources,

   -    Traffic pattern confidentiality is strongly desired by
        several communities[9] and [5].

Time Frame
     Security should be an integral component of any IPng from
     the beginning.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 23]

Internet Draft      IPng Technical Criteria           May 1994

5.10.  Unique Naming

     IPng must assign all IP-Layer objects in the global,
     ubiquitous, Internet unique names.  These names may or
     may not have any location, topology, or routing

     We use the term "Name" in this criterion synonymously
     with the term "End Point Identifier" as used in the
     NIMROD proposal, or as IP Addresses uniquely identify
     interfaces/hosts in IPv4.  These names may or may not
     carry any routing or topology information.  See [11] for
     more discussion on this topic.

     IPng must provide identifiers which are suitable for use
     as globally unique, unambiguous, and ubiquitous names for
     endpoints, nodes, interfaces, and the like.  Every
     datagram must carry the identifier of both its source and
     its destination (or some method must be available to
     determine these identifiers, given a datagram).  We
     believe that this is required in order to support certain
     accounting functions.

     Other functions and uses of unique names are:

   -    To uniquely identify endpoints (thus if the unique
        name and address are not the same, the TCP pseudo-
        header should include the unique name rather than the

   -    To allow endpoints to change topological location on
        the network (e.g., migrate) without changing their
        unique names.

   -    To give one or more unique names to a node on the
        network (i.e., one node may have multiple unique

     An identifier must refer to one and only one object while
     that object is in existence.  Furthermore, after an
     object ceases to exist, the identifier should be kept
     unused long enough to ensure that any packets containing
     the identifier have drained out of the Internet system,

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 24]

Internet Draft      IPng Technical Criteria           May 1994

     and that other references to the identifier have probably
     been lost.  We note that the term "existence" is as much
     an administrative issue as a technical one.  For example,
     if a workstation is reassigned, given a new IP address
     and node name, and attached to a new subnetwork, is it
     the same object or not.  This does argue for a namespace
     that is relatively large and relatively stable.

Time Frame
     We see this as a fundamental element of the IP layer and
     it should be in the protocol from the beginning.

5.11.  Access

     The protocols that define IPng, its associated protocols
     (similar to ARP and ICMP in IPv4) and the routing
     protocols (as in OSPF, BGP, and RIP for IPv4) must be
     published as standards track RFCs and must satisfy the
     requirements specified in RFC1310.  These documents
     should be as freely available and redistributable as the
     IPv4 and related RFCs.  There must be no specification-
     related licensing fees for implementing or selling IPng

     An essential aspect of the development of the Internet
     and its protocols has been the fact that the protocol
     specifications are freely available to anyone who wishes
     a copy.  Beyond simply minimizing the cost of learning
     about the technology, the free access to specifications
     has made it easy for researchers and developers to easily
     incorporate portions of old protocol specifications in
     the revised specifications.  This type of easy access to
     the standards documents is required for IPng.

Time Frame
     An IPng and its related protocols must meet these
     standards for openness before an IPng can be approved.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 25]

Internet Draft      IPng Technical Criteria           May 1994

5.12.  Multicast

     The protocol must support both unicast and multicast
     packet transmission.  Part of the multicast capability is
     a requirement to be able to send to "all IP hosts on a
     given subnetwork".  Dynamic and automatic routing of
     multicasts is also required.

     IPv4 has made heavy use of the ability to multicast
     requests to all IPv4 hosts on a subnet, especially for
     autoconfiguration.  This ability must be retained in

     Unfortunately, IPv4 currently uses the local media
     broadcast address to multicast to all IP hosts.  This
     behavior is anti-social in mixed-protocol networks and
     should be fixed in IPng.  There's no good reason for IPng
     to send to all hosts on a subnet when it only wishes to
     send to all IPng hosts.  The protocol must make
     allowances for media that do not support true

     In the past few years, we have begun to deploy support
     for wide-area multicast addressing in the Internet, and
     it has proved valuable.  This capability must not be lost
     in the transition to IPng.

     The ability to restrict the range of a multicast to
     specific networks is also important.  Furthermore, it
     must be possible to "selectively" multicast packets. That
     is, it must be possible to send a multicast to a remote,
     specific portion or area of the Internet (such as a
     specific network or subnetwork) and then have that
     multicast limited to just that specific area.
     Furthermore, any given network or subnetwork should be
     capable of supporting 2**16 "local" multicast groups,
     i.e. groups that are not propagated to other networks.
     See [8].

     It should be noted that addressing -- specifically the
     syntax and semantics of addresses -- has a great impact
     on the scalability of the architecture.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 26]

Internet Draft      IPng Technical Criteria           May 1994

     Currently, large-scale multicasts are routed manually
     through the Internet.  While this is fine for
     experiments, a "production" system requires that
     multicast-routing be dynamic and automatic.  Multicast
     groups must be able to be created and destroyed, hosts
     must be able to join and leave multicast groups and the
     network routing infrastructure must be able to locate new
     multicast groups and destinations and route traffic to
     those destinations all without manual intervention.

     Large, topologically dispersed, multicast groups (with up
     to 10**6 participants) must be supported.  Some
     applications are given in [8].

Time Frame
     Obviously, address formats, algorithms for processing and
     interpreting the multicast addresses must be immediately
     available in IPng.  Broadcast and Multicast
     transmission/reception of packets are required
     immediately.  Dynamic routing of multicast packets must
     be available within 18 months.

     We believe that Multicast Addressing is vital to support
     future applications such as remote conferencing.  It is
     also used quite heavily in the current Internet for
     things like service location and routing.

5.13.  Extensibility

     The protocol must be extensible; it must be able to
     evolve to meet the future service needs of the Internet.
     This evolution must be achievable without requiring
     network-wide software upgrades.  IPng is expected to
     evolve over time. As it evolves, it must be able to allow
     different versions to coexist on the same network.

     We do not today know all of the things that we will want
     the Internet to be able to do 10 years from now.  At the
     same time, it is not reasonable to ask users to
     transition to a new protocol with each passing decade.
     Thus, we believe that it must be possible to extend IPng
     to support new services and facilities.  Furthermore, it

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 27]

Internet Draft      IPng Technical Criteria           May 1994

     is essential that any extensions can be incrementally
     deployed to only those systems which desire to use them.
     Systems upgraded in this fashion must still be able to
     communicate with systems which have not been so upgraded.

     There are several aspects to extensibility:

        The algorithms used in processing IPng information
        should be decoupled from the protocol itself.  It
        should be possible to change these algorithms without
        necessarily requiring protocol, datastructure, or
        header changes.

        The content of packet headers should be extensible.
        As more features and functions are required of IPng,
        it may be necessary to add more information to the
        IPng headers.  We note that for IPv4, the use of
        options has proven less than entirely satisfactory
        since options have tended to be inefficient to

   Data Structures
        The fundamental data structures of IPng should not be
        bound with the other elements of the protocol.  E.g.,
        things like address formats should not be intimately
        tied with the routing and forwarding algorithms in the
        way that the IPv4 address class mechanism was tied to
        IPv4 routing and forwarding.

        It should be possible to add additional packet-types
        to IPng.  These could be for, e.g., new control and/or
        monitoring operations.

     We note that, everything else being equal, having larger,
     oversized, number spaces is preferable to having number
     spaces that are "just large enough".  Larger spaces
     afford more flexibility on the part of network designers
     and operators and allow for further experimentation on
     the part of the scientists, engineers, and developers.
     See [7].

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 28]

Internet Draft      IPng Technical Criteria           May 1994

Time Frame
     A framework showing mechanisms for extending the protocol
     must be provided immediately.

5.14.  Network Service

     The protocol must allow the network (routers, intelligent
     media, hosts, and so on) to associate packets with
     particular service classes and provide them with the
     services specified by those classes.

     For many reasons, such as accounting, security and
     multimedia, it is desirable to treat different packets
     differently in the network.

     For example, multimedia is now on our desktop and will be
     an essential part of future networking.  So we have to
     find ways to support it; and a failure to support it may
     mean users choose to use protocols other than IPng.

     The IETF multicasts have shown that we can currently
     support multimedia over internetworks with some hitches.
     If the network can be guaranteed to provide the necessary
     service levels for this traffic, we will dramatically
     increase its success.

     This criterion includes features such as policy-based
     routing, flows, resource reservation, network service
     technologies, type-of-service and quality-of-service and
     so on.

     In order to properly support commercial provision and use
     of Internetwork service, and account for the use of these
     services (i.e. support the economic principle of "value
     paid for value received") it must be possible to obtain
     guarantees of service levels.  Similarly, if the network
     can not support a previously guaranteed service level, it
     must report this to those to whom it guaranteed the

     Network service provisions must be secure.  The network-
     layer security must generally prevent one host from

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 29]

Internet Draft      IPng Technical Criteria           May 1994

     surreptitiously obtaining or disrupting the use of
     resources which another host has validly acquired.  (Some
     security failures are acceptable, but the failure rate
     must be very low and the rate should be quantifiable).

     One of the parameters of network service that may be
     requested must be cost-based.

     As far as possible, given the limitations of underlying
     media and IP's model of a robust internet datagram
     service, real-time, mission-critical applications must be
     supported by IPng[6].

     Users must be able to confirm that they are, in fact,
     getting the services that they have requested.

Time Frame
     This should be available within 24 months.

5.15.  Support for Mobility

     The protocol must support mobile hosts, networks and

     Again, mobility is becoming increasingly important.  Look
     at the portables that everyone is carrying.  Note the
     strength of the Apple commercial showing someone
     automatically connecting up her Powerbook to her computer
     back in the office.  There have been a number of pilot
     projects showing ways to support mobility in IPv4.  All
     have some drawbacks.  But like network service grades, if
     we can support mobility, IPng will have features that
     will encourage transition.

     We use an encompassing definition of "mobility" here.
     Mobility typically means one of two things to people: 1)
     Hosts that physically move and remain connected (via some
     wireless datalink) with sessions and transport-layer
     connections remaining 'open' or 'active' and 2)
     Disconnecting a host from one spot in the network,
     connecting it back in another arbitrary spot and
     continuing to work.  Both forms are required.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 30]

Internet Draft      IPng Technical Criteria           May 1994

     Reference [6] discusses possible future use of IP-based
     networks in the US Navy's ships, planes, and shore
     installations.  Their basic model is that each ship,
     plane and shore installation represents at least one IP
     network.  The ship- and plane-based networks, obviously,
     are mobile as these craft move around the world.
     Furthermore, most, if not all, Naval surface combatants
     carry some aircraft (at a minimum, a helicopter or two).
     So, not only must there be mobile networks (the ships
     that move around), but there must be mobile
     internetworks: the ships carrying the aircraft where each
     aircraft has its own network, which is connected to the
     ship's network and the whole thing is moving.

     There is also the requirement for dynamic mobility; a
     plane might take off from aircraft carrier A and land on
     carrier B so it obviously would want to "connect" to B's
     network.  This situation might be even more complex since
     the plane might wish to retain connectivity to its "home"
     network; that is, the plane might remain connected to the
     ship-borne networks of both aircraft carriers, A and B.

     These requirements are not limited to just the navy.
     They apply to the civilian and commercial worlds as well.
     For example, in civil airliners, commercial cargo and
     passenger ships, trains, cars and so on.

Time Frame
     The mobility algorithms are stabilizing and we would hope
     to see an IPng mobility framework within a year.

5.16.  Control Protocol

     The protocol must include elementary support for testing
     and debugging networks.

     An important feature of IPv4 is the ICMP and its
     debugging, support, and control features.  Specific ICMP
     messages that have proven extraordinarily useful within
     IPv4 are Echo Request/Reply (a.k.a ping), Destination
     Unreachable and Redirect.  Functions similar to these
     should be in IPng.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 31]

Internet Draft      IPng Technical Criteria           May 1994

     This criterion explicitly does not concern itself with
     configuration related messages of ICMP.  We believe that
     these are adequately covered by the configuration
     criterion in this memo.

     One limitation of today's ICMP that should be fixed in
     IPng's control protocol is that more than just the IPng
     header plus 64 bits of a failed datagram should be
     returned in the error message.  In some situations, this
     is too little to carry all the critical protocol
     information that indicates why a datagram failed.  At
     minimum, any IPng control protocol should return the
     entire IPng and transport headers (including options or
     nested headers).

Time Frame
     Support for these functions is required immediately.

5.17.  Private Networks

     IPng must allow users to build private internetworks on
     top of the basic Internet Infrastructure.  Both private
     IP-based internetworks and private non-IP-based (e.g.,
     CLNP or Appletalk) internetworks must be supported.

     In the current Internet, these capabilities are used by
     the research community to develop new IP services and
     capabilities (e.g. the MBone) and by users to
     interconnect non-IP islands over the Internet (e.g. CLNP
     and DecNet use in the UK).

     The capability of building networks on top of the
     Internet have been shown to be useful.  Private networks
     allow the Internet to be extended and modified in ways
     that 1) were not foreseen by the original builders and 2)
     do not disrupt the day-to-day operations of other users.

     We note that, today in the IPv4 Internet, tunneling is
     widely used to provide these capabilities.

     Finally, we note that there might not be any features
     that specifically need to be added to IPng in order to

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 32]

Internet Draft      IPng Technical Criteria           May 1994

     support the desired functions (i.e. one might treat a
     private network protocol simply as another IP client
     protocol, just like TCP or UDP). If this is the case,
     then IPng must not prevent these functions from being

Time Frame
     Some of these capabilities may be required to support
     other criteria (e.g. transition) and as such, the timing
     of the specifications is governed by the other criteria
     (e.g. immediately in the case of transition).  Others may
     be produced as desired.

5.18.  Things We Chose Not to Require

This section contains items which we felt should not impact
the choice of an IPng.  Listing an item here does not mean
that a protocol MUST NOT do something. It means that the
authors do not believe that it matters whether the feature is
in the protocol or not. If a protocol includes one of the
items listed here, that's cool. If it doesn't; that's cool
too. A feature might be necessary in order to meet some other
criterion.  Our point is merely that the feature need not be
required for its own sake.

     The technology exists for path MTU discovery.
     Presumably, IPng will continue to provide this
     technology.  Therefore, we believe that IPng
     Fragmentation and Reassembly, as provided in IPv4, is not
     necessary.  We note that fragmentation has been shown to
     be detrimental to network performance and strongly
     recommend that it be avoided.

IP Header Checksum
     There has been discussion indicating that the IP Checksum
     does not provide enough error protection to warrant its
     performance impact.  The argument states that there is
     almost always a stronger datalink level CRC, and that
     end-to-end protection is provided by the TCP checksum.
     Therefore we believe that an IPng checksum is not
     required per-se.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 33]

Internet Draft      IPng Technical Criteria           May 1994

     Some have requested that IPng include support for
     firewalls.  The authors believe that firewalls are one
     particular solution to the problem of security and, as
     such, do not consider that support for firewalls is a
     valid requirement for IPng.  (At the same time, we would
     hope that no IPng is hostile to firewalls without
     offering some equivalent security solution).

Network Management
     Network Management properly is a task to be carried out
     by additional protocols and standards, such as SNMP and
     its MIBs.  We believe that network management, per se, is
     not an attribute of the IPng protocol.  Furthermore,
     network management is viewed as a support, or service,
     function. Network management should be developed to fit
     IPng and not the other way round.

     We believe that accounting, like network management, must
     be designed to fit the IPng protocol, and not the other
     way round.  Therefore, accounting, in and of itself, is
     not a requirement of IPng.  However, there are some
     facets of the protocol that have been specified to make
     accounting easier, such as non-repudiation of origin
     under security, and the unique naming requirement for
     sorting datagrams into classes.  Note that a parameter of
     network service that IPng must support is cost.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 34]

Internet Draft      IPng Technical Criteria           May 1994

6.  Routing

Routing is a very critical part of the Internet.  In fact, the
Internet Engineering Task Force has a separate Area which is
chartered to deal only with routing issues.  This Area is
separate from the more general Internet Area.

We see that routing is also a critical component of IPng.
There are several criteria, such as Scaling, Addressing, and
Network Services, which are intimately entwined with routing.
In order to stress the critical nature and importance of
routing, we have chosen to devote a separate chapter to
specifically enumerating some of the requirements and issues
that IPng routing must address.  All of these issues, we
believe, fall out of the general criteria presented in the
previous chapter.

6.1.  Scale

First and foremost, the routing architecture must scale to
support a very large Internet.  Current expectations are for
an Internet of about 10**9 to 10**12 networks.  The routing
architecture must be able to deal with networks of this size.
Furthermore, the routing architecture must be able to deal
with this size without requiring massive, global databases and
algorithms.  Such databases or algorithms would, in effect, be
single points of failure in the architecture (which is not
robust), and because of the nature of Internet administration
(cooperative anarchy), it would be impossible to maintain the
needed consistency.

6.2.  Policy

Networks (both transit and non-transit) must be able to set
their own policies for the types of traffic that they will
admit.  The routing architecture must make these policies
available to the network as a whole.  Furthermore, nodes must
be able to select routes for their traffic based on the
advertised policies.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 35]

Internet Draft      IPng Technical Criteria           May 1994

6.3.  QOS

A key element of the network service criteria is that
differing applications wish to acquire differing grades of
network service.  It is essential that this service
information be propagated around the network.

6.4.  Feedback

As users select specific routes over which to send their
traffic, they must be provided feedback from the routing
architecture. This feedback should allow the user to determine
whether the desired routes are actually available or not,
whether the desired services are being provided, and so forth.

This would allow users to modify their service requirements or
even change their routes, as needed.

6.5.  Stability

With the addition of additional data into the routing system
(i.e. routes are based not only on connectivity, as in IPv4,
but also on policies, service grades, and so on), the
stability of the routes may suffer.  We offer as evidence the
early Arpanet which experimented with load-based routing.
Routes would remain in flux, changing from one saturated link,
to another, unused, link.

This must not be allowed to happen.  If anything, routes
should be even more stable under IPng's routing architecture
than under the current architecture.

6.6.  Multicast

Multicast will be more important in IPng than it is today in
IPv4.  Multicast groups may be very large and very
distributed.  Membership in multicast groups will be very
dynamic.  The routing architecture must be able to cope with

Furthermore, the routing architecture must be able to build
multicast routes dynamically, based on factors such as group

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 36]

Internet Draft      IPng Technical Criteria           May 1994

membership, member location, requested and available qualities
of service, and so on.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 37]

Internet Draft      IPng Technical Criteria           May 1994

7.  Security Considerations

Security is not directly addressed by this memo.  However, as
this memo codifies goals for a new generation of network layer
protocol, the security provided by such a protocol is
addressed.  Security has been raised as an issue in several of
the requirements stated in this memo.  Furthermore, a specific
requirement for security has been made.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 38]

Internet Draft      IPng Technical Criteria           May 1994

8.  Acknowledgments

The authors gratefully acknowledge the assistance and input
provided by the many people who have reviewed and commented
upon this document.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 39]

Internet Draft      IPng Technical Criteria           May 1994

9.  References

[1]  Internet Architecture Board, IP Version 7, Draft 8,
     Internet Draft, July, 1992.

[2]  Gross, P. and P. Almquist, IESG Deliberations on Routing
     and Addressing, Internet Draft, September 1992.

[3]  Clark, D., et al, Towards the Future Internet
     Architecture Network Working Group Request For Comments
     1287, December 1991.

[4]  Dave Clark's paper at SIGCOMM '88 where he pointed out
     that the design of TCP/IP was guided, in large part, by
     an ordered list of requirements.

[5]  Vecchi, Mario P., IPng Requirements: A Cable Television
     Industry Viewpoint, Time Warner Cable, January 1994.  To
     Be Published as an Internet Draft.

[6]  Green, D., P. Irey, D. Marlow, and K. O'Donoghue HPN
     Working Group Input to the IPng Requirements
     Solicitation, NSWC-DD, January 1994.  To Be Published.

[7]  Bellovin, S., On Many Addresses per Host, AT&T Bell
     Laboratories, February 1994.  To Be Published.

[8]  Symington, S., D Wood, and J.M. Pullen, Modelling and
     Simulation Requirements for IPng, Mitre Corporation and
     George Mason University, January 1994.  To Be Published.

[9]  Internet Architecture Board, Report of the IAB Workshop
     on Security in the Internet Architecture, March 1994.  To
     Be Published.

     Private EMAIL from Tony Li to IPNG Directorate Mailing
     List, 18 April 1994 18:42:05.

     Saltzer, J., On the Naming and Binding of Network
     Destinations, RFC 1498, August 1993.

     Postel, J., Transmission Control Protocol RFC 793,

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 40]

Internet Draft      IPng Technical Criteria           May 1994

     September, 1981.

     EMAIL from Robert Elz to the Big Internet mailing list,
     approximately 4 May 1994.

     Chiappa, J. Noel, Nimrod and IPng Technical Requirements
     Work in progress.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 41]

Internet Draft      IPng Technical Criteria           May 1994

10.  Change Log

10.1.  25 May 1994

This is for the final draft.

 (1)   Added text to performance section indicating that word
       alignment is a good thing, also suggested that
       designers think 20 years ahead, not for today's

 (2)   Several minor editorial changes were made.

10.2.  10 May 1994

This is the edits for the final draft in preparation for
attending the IPng directorate workshop in Chicago on 19/20
May 1994.

 (1)   Referenced RFC 1498 in the unique naming section.

 (2)   Added a statement on the lifetime of the 'unique name'.
       It must last as long as the thing it names lasts.

 (3)   Added text clarifying the topological significance of
       the unique-name.

 (4)   In topological flexibility, added text saying that the
       network will not be a tree....

 (5)   Added additional text on the power and usefulness of

 (6)   Several minor editorial changes were made.

10.3.  25 April 1994

 (1)   Several minor edorial changes were made

 (2)   Changed the section called "Tunneling" into "Private

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 42]

Internet Draft      IPng Technical Criteria           May 1994

 (3)   Strengthened the scaling requirements - routing tables
       must scale as the square root (or less) of the nr
       networks in the system

10.4.  23 March 1994

The following changes were made in response to consultations
with Craig Partridge on the changes made on 21 March.

 (1)   Moved the log to the back of the document....

 (2)   Made autoconfig "mandatory"; pointed out that other
       issues (registering with DNS, etc) are important but
       not IP -- IPng must not prevent the development of
       these technologies.

 (3)   The requirements for mission critical, realtime have
       been weakened a bit to say something to the effect of
       "As far as possible, given limitations of underlying

 (4)   The word Broadcast has been exorcised from where it
       does not belong in the multicast address section.

 (5)   In the statement on large number spaces, we've stressed
       thje everything else being equal bit.

10.5.  21 March 1994

The following changes were made in response to the phone
teleconference with the IPng directorate earlier today:

 (1)   Change IP:ng to IPng

 (2)   Change title to "Technical Criteria..."

 (3)   Give a pointer to the big-internet mailing list.

 (4)   Some additional text was added to "Architectural
       Simplicity", describing that some functions are best
       left to other, non-IP, elements of the stack and in
       such cases, IP should keep out of the way.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 43]

Internet Draft      IPng Technical Criteria           May 1994

 (5)   The scale requirement has been changed to indicate "at
       least" 10**9/10**12 and a comment has been added that,
       interpreting one of the white papers, these could be
       off by 3 orders of magnitude....

 (6)   The section on Media has been renamed Media

 (7)   Changed paragraph in the transition section to say that
       multiple versions of IPng will exist as it evolves, and
       coexistance of these versions on the net is required.

 (8)   Spelled out Van's name.

 (9)   Timeframe for Media section now requires that ipng
       support all encapsulations that are currently
       standardized by the IETF.

 (10)  Auto registration added to Config...

 (11)  Auto config, etc, made an immediate requirement.

 (12)  Changed section title to Multicast Addressing from

 (13)  Added mobile networks to the Mobility section --
       derived from one of the white papers.

 (14)  Stress that fragmentation is harmful and recommend
       against it.

 (15)  The IPv4/IPng communication non-requirement has been

 (16)  Added text on host performance.

 (17)  Added a top-level requirement for tunneling.

 (18)  Added a preference for larger rather than smaller
       number spaces in Extensibility.

 (19)  Cost explicitly made a parameter of network service
       that a client may request.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 44]

Internet Draft      IPng Technical Criteria           May 1994

 (20)  Added a requirement for the scale of multicast groups.
       Also added requirements for "locality" and
       "directability" of multi/broad-cast.

 (21)  In performance section, say that [5] are considering
       that connections at OC-3 or better rates might become

 (22)  IP security must be able to prevent traffic pattern

 (23)  Broadened network services to indicate that real-time,
       mission, critical applications are required.

 (24)  Make minor spelling, editorial and grammatical changes.

10.6.  10 March 1994

 (1)   A new general principle, Cooperative Anarchy, has been

 (2)   Cleaned up some of the text in "Forwarding Performance"

 (3)   Clarified the "Time Scale" for "Forwarding Performance"

 (4)   Clarified the "Time Scale" for "Access"

 (5)   Made the "Time Scale" for "Configuration" more

 (6)   Added sections for Security Considerations and

 (7)   Minor editorial changes, fix typos, and the like.

10.7.  9 March 1994

 (1)   Additional text clarifying the intent of
       "extensibility" has been added. This covers things like
       algorithms, packet headers, data structures, and so on.

 (2)   A brief paragraph in "Media" has been added indicating
       that ATM seems to be set to be a major network
       technology and IPng should be able to deal with this.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 45]

Internet Draft      IPng Technical Criteria           May 1994

 (3)   More text has been added to the "robust service"
       section.  This text describes a network that suffers
       more outages, due to increased size, and is the target
       of more errors, due to increasingly less sophisticated
       users and requires that the network protects against
       these problems.

 (4)   A statement was made indicating that large diameter
       networks are possible.

 (5)   Added a pointer to RFC1310 to the Access criterion.

 (6)   A brief discussion of the meaning of Time Frame was

 (7)   A high end speed of 500 gig within 10 years is
       specified in Media.

 (8)   A section on performance has been added (per
       discussions with DDC).

 (9)   A couple new non-goals have been stated.

 (10)  Additional text describing the unreliable datagram
       service has been added.

 (11)  Additional descriptive text has been added to the
       Unique Naming criterion.

 (12)  Additional descrioptions in Media on coexistance with
       intelligent subnetwork technologies.

 (13)  Reworded "flows" to be "network service".

10.8.  15 February 1994

 (1)   Deleted the explicit placement paragraphs. Either
       deleted that text outright or kept it, without a
       header, or moved the text into the main body of the

 (2)   Deleted the SHOULD/MUST model. Replaced it with a
       proposed timescale for which there is an explicit
       paragraph for each criterion.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 46]

Internet Draft      IPng Technical Criteria           May 1994

 (3)   Added dynamic/automatic routing to multicasts.

 (4)   Extended guaranteed flows to include the resource
       reservation, tos/qos, and and internet services work.

 (5)   added a requirement for some of the more useful parts
       of icmp (ping, redirect, unreachable).

10.9.  9 November 1993

The following changes have been made for the 9 November 1993
version of the document.

 (1)   References to "IP Version 7" or "IPv7" have been
       changed to IP: The Next Generation or IPng to reflect
       the IETF's political silliness.

 (2)   The "origin" of the document was changed to be the
       authors' personal opinions rather than the product of
       the IETF or other organized (or disorganized) body.

 (3)   Topological flexibility was extended to indicate that
       constituent organizations should be free to arrange
       their own internal topologies in any manner they see
       fit. If hierarchical addressing/topology is used, then
       these organizations should be able to allocate as many
       layers of the hierarchy to themselves as they see fit.

 (4)   Robustness is extended to include keeping effects of
       errors and failures localized.

 (5)   The media section has been extended to state that
       multiple MAC addressing schemes exist and that a
       mechanism must be provided to associate an IP Address
       with the MAC address of its node. No static tables

 (6)   All IP parameters obtainable at boot time.

 (7)   Multicast has been moved to the MUST section, per our

 (8)   All specifications must be available as RFCs and freely
       available and redistributable, per the RFC tradition.
       This strengthens previous working group positions

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 47]

Internet Draft      IPng Technical Criteria           May 1994

       according to the authors' opinions.

 (9)   Minor editorial changes have been made, spelling and
       grammar errors were fixed, additional explanatory text

10.10.  9 September 1993

The following changes have been made for the 9 September 1993
version of the document. This version was not published.

 (1)   Multi-protocol co-existence was added in the Media

 (2)   Minor editorial changes have been made, spelling and
       grammar errors were fixed, additional explanatory text

10.11.  14 December 1992

At the Washington D.C. IETF meeting, a BOF was held during
which this document was discussed. The following changes have
been made to reflect that discussion.

 (1)   The list has been changed from an ordered list of
       criteria, where each criterion was considered "more
       important" than those that followed to a split into two
       groups: (A) those criteria which the new IP "must"
       have, where "must" is defined by agreeing that a new
       IPng will not be accepted or deployed unless it
       fulfills all the "must" requirements; and (B) those
       criteria which it would be desirable to have in the new
       IP but are not a pre-requisite for deployment.

     This change has engendered most of the editorial work on
     the document.  Most notably, references to "ordered
     lists" had to be reworded, and the document needed to be
     re-organized to have must and should subsections.

 (2)   A section called "General Principles" has been added to
       the beginning of the document. This section contains
       those items discussed that are hard to quantify as
       criteria for the protocol, yet which we believe are

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 48]

Internet Draft      IPng Technical Criteria           May 1994

       essential to the future success of IPng and the
       Internet as a whole.

 (3)   Discussion at the BOF made it clear that it would be
       desirable to refine the criteria into questions that
       could be used to help distinguish proposals.  The goal
       of these questions is not to grade proposals, and
       determine which one becomes IPng, but rather to help
       elucidate the various ways that the different proposals
       try to meet the criteria.  A beginning of this process,
       in the form of a section of detailed questions has been
       added to the end of the document.

 (4)   A MUST criterion for "documents being on-line and owned
       by the IETF" has been added per the BOF.

 (5)   Per the BOF, the section on accounting has been

 (6)   Several criteria were mentioned at the BOF but we could
       find no reasonable definition of them. Place-holders
       for these criteria are given, but no discussion of them
       is given. We hope that these place-holders will
       stimulate discussion on the mailing list. If not, they
       will be deleted.

 (7)   The IP Checksum was made a non-goal. There has been
       sufficient discussion on the big-i mailing list to
       suggest that it does not provide significant data

 (8)   Some typos were fixed. Some additional explanatory text
       has been added.

 (9)   Additional parts added to the "Configuration,
       Administration, and Operation" section per the
       discussion at the BOF.

 (10)  The "Scale" criterion has been expanded per the BOF to
       address 10**12 nodes and requesting a description of
       the performance as the limit is reached.

 (11)  Robust Service includes a mention of Hostile attacks
       and Byzantine failures.

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 49]

Internet Draft      IPng Technical Criteria           May 1994


Partridge & Kastenholz Exp. 30 Nov. 1994             [Page 50]

Internet Draft      IPng Technical Criteria           May 1994

Table of Contents

 Status of this Memo ....................................    1
1 Introduction ..........................................    2
2 Goals .................................................    3
3 Note on Terminology ...................................    5
4 General Principles ....................................    6
4.1 Architectural Simplicity ............................    6
4.2 One Protocol to Bind Them All .......................    6
4.3 Live Long ...........................................    6
4.4 Live Long AND Prosper ...............................    7
4.5 Co-operative Anarchy ................................    7
5 Criteria ..............................................    9
5.1 Scale ...............................................    9
5.2 Topological Flexibility .............................   11
5.3 Performance .........................................   12
5.4 Robust Service ......................................   14
5.5 Transition ..........................................   15
5.6 Media Independence ..................................   17
5.7 Unreliable Datagram Service .........................   19
5.8 Configuration, Administration, and Operation ........   20
5.9 Secure Operation ....................................   22
5.10 Unique Naming ......................................   24
5.11 Access .............................................   25
5.12 Multicast ..........................................   26
5.13 Extensibility ......................................   27
5.14 Network Service ....................................   29
5.15 Support for Mobility ...............................   30
5.16 Control Protocol ...................................   31
5.17 Private Networks ...................................   32
5.18 Things We Chose Not to Require .....................   33
6 Routing ...............................................   35
6.1 Scale ...............................................   35
6.2 Policy ..............................................   35
6.3 QOS .................................................   36
6.4 Feedback ............................................   36
6.5 Stability ...........................................   36
6.6 Multicast ...........................................   36
7 Security Considerations ...............................   38
8 Acknowledgments .......................................   39
9 References ............................................   40
10 Change Log ...........................................   42
10.1 25 May 1994 ........................................   42
10.2 10 May 1994 ........................................   42

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page li]

Internet Draft      IPng Technical Criteria           May 1994

10.3 25 April 1994 ......................................   42
10.4 23 March 1994 ......................................   43
10.5 21 March 1994 ......................................   43
10.6 10 March 1994 ......................................   45
10.7 9 March 1994 .......................................   45
10.8 15 February 1994 ...................................   46
10.9 9 November 1993 ....................................   47
10.10 9 September 1993 ..................................   48
10.11 14 December 1992 ..................................   48

Partridge & Kastenholz Exp. 30 Nov. 1994             [Page ii]