[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/