RFC 1726 (rfc1726) - Page 3 of 31

Technical Criteria for Choosing IP The Next Generation (IPng)

RFC 1726                IPng Technical Criteria            December 1994


   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.

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 IPng.

   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 specification.

   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



Partridge and Kastenholz