rfc1454.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 843 行 · 第 1/3 页

Network Working Group                                          T. Dixon
Request for Comments: 1454                                         RARE
                                                               May 1993


             Comparison of Proposals for Next Version of IP

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This is a slightly edited reprint of RARE Technical Report
   (RTC(93)004).

   The following is a brief summary of the characteristics of the three
   main proposals for replacing the current Internet Protocol. It is not
   intended to be exhaustive or definitive (a brief bibliography at the
   end points to sources of more information), but to serve as input to
   the European discussions on these proposals, to be co-ordinated by
   RARE and RIPE. It should be recognised that the proposals are
   themselves "moving targets", and in so far as this paper is accurate
   at all, it reflects the position at the 25th IETF meeting in
   Washington, DC. Comments from Ross Callon and Paul Tsuchiya on the
   original draft have been incorporated.  Note that for a time the term
   "IPv7" was use to mean the eventual next version of IP, but that the
   same term was closely associated with a particilar proposal, so the
   term "IPng" is now used to identify the eventual next generation of
   IP.

   The paper begins with a "generic" discussion of the mechanisms for
   solving problems and achieving particular goals, before discussing
   the proposals invidually.

1. WHY IS THE CURRENT IP INADEQUATE?

   The problem has been investigated and formulated by the ROAD group,
   but briefly reduces to the following:

      - Exhaustion of IP Class B Address Space.

      - Exhaustion of IP Address Space in General.

      - Non-hierarchical nature of address allocation leading to flat
        routing space.



Dixon                                                           [Page 1]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


   Although the IESG requirements for a new Internet Protocol go further
   than simply routing and addressing issues,  it is these issues that
   make extension of the current protocol an impractical option.
   Consequently, most of the discussion and development of the various
   proposed protocols has concentrated on these specific problems.

   Near term remedies for these problems include the CIDR proposals
   (which permit the aggregation of Class C networks for routing
   purposes) and assignment policies which will allocate Class C network
   numbers in a fashion which CIDR can take advantage of. Routing
   protocols supporting CIDR are OSPF and BGP4. None of these are pre-
   requisites for the new IP (IPng), but are necessary to prolong the
   life of the current Internet long enough to work on longer-term
   solutions. Ross Callon points out that there are other options for
   prolonging the life of IP and that some ideas have been distributed
   on the TUBA list.

   Longer term proposals are being sought which ultimately allow for
   further growth of the Internet. The timescale for considering these
   proposals is as follows:

      - Dec 15 Issue selection criteria as RFC.

      - Feb 12 Two interoperable implementations available.

      - Feb 26 Second draft of proposal documents available.

   The (ambitious) target is for a decision to be made at the 26th IETF
   (Columbus, Ohio in March 1993) on which proposals to pursue.

   The current likely candidates for selection are:

      - PIP ('P' Internet Protocol - an entirely new protocol).

      - TUBA (TCP/UDP with Big Addresses - uses ISO CLNP).

      - SIP (Simple IP - IP with larger addresses and fewer options).

   There is a further proposal from Robert Ullman of which I don't claim
   to have much knowledge. Associated with each of the candidates are
   transition plans, but these are largely independent of the protocol
   itself and contain elements which could be adopted separately, even
   with IP v4, to further extend the life of current implementations and
   systems.







Dixon                                                           [Page 2]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


2. WHAT THE PROPOSALS HAVE IN COMMON

2.1 Larger Addresses

   All the proposals (of course) make provision for larger address
   fields which not only increase the number of addressable systems, but
   also permit the hierarchical allocation of addresses to facilitate
   route aggregation.

2.2 Philosophy

   The proposals also originate from a "routing implementation" view of
   the world - that is to say they focus on the internals of routing
   within the network and do not primarily look at the network service
   seen by the end-user, or by applications. This is perhaps inevitable,
   especially given the tight time constraints for producing
   interoperable implementations. However, the (few) representatives of
   real users at the 25th IETF, the people whose support is ultimately
   necessary to deploy new host implementations, were distinctly
   unhappy.

   There is an inbuilt assumption in the proposals that IPng is
   intended to be a universal protocol: that is, that the same network-
   layer protocol will be used between hosts on the same LAN, between
   hosts and routers, between routers in the same domain, and between
   routers in different domains. There are some advantages in defining
   separate "access" and "long-haul" protocols, and this is not
   precluded by the requirements. However, despite the few opportunities
   for major change of this sort within the Internet, the need for speed
   of development and low risk have led to the proposals being
   incremental, rather than radical, changes to well-proven existing
   technology.

   There is a further unstated assumption that the architecture is
   targeted at the singly-connected host. It is currently difficult to
   design IPv4 networks which permit hosts with more than one interface
   to benefit from increased bandwidth and reliability compared with
   singly-connected hosts (a consequence of the address belonging to the
   interface and not the host). It would be preferable if topological
   constraints such as these were documented. It has been asserted that
   this is not necessarily a constraint of either the PIP or TUBA
   proposals, but I believe it is an issue that has not emerged so far
   amongst the comparative criteria.








Dixon                                                           [Page 3]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


2.3 Source Routing

   The existing IPv4 has provision for source-specified routes, though
   this is little used [would someone like to contradict me here?],
   partly because it requires knowledge of the internal structure of the
   network down to the router level. Source routes are usually required
   by users when there are policy requirements which make it preferable
   or imperative that traffic between a source and destination should
   pass through particular administrative domains. Source routes can
   also be used by routers within administrative domains to route via
   particular logical topologies. Source-specified routing requires a
   number of distinct components:

      a.  The specification by the source of the policy by which the
          route should be selected.

      b.  The selection of a route appropriate to the policy.

      c.  Marking traffic with the identified route.

      d.  Routing marked traffic accordingly.

   These steps are not wholly independent. The way in which routes are
   identified in step (c) may constrain the kinds of route which can be
   selected in previous steps. The destination, inevitably, participates
   in the specification of source routes either by advertising the
   policies it is prepared to accept or, conceivably, by a negotiation
   process.

   All of the proposals mark source routes by adding a chain of (perhaps
   partially-specified) intermediate addresses to each packet. None
   specifies the process by which a host might acquire the information
   needed to  specify these intermediate addresses [not entirely
   unreasonably at this stage, but further information is expected]. The
   negative consequences of these decisions are:

      - Packet headers can become quite long, depending on the number of
        intermediate addresses that must be specified (although there are
        mechanisms which are currently specified or which can be imagined
        to specify only the significant portions of intermediate addresses).

      - The source route may have to be re-specified periodically if
        particular intermediate addresses are no longer reachable.

   The positive consequences are:

      - Inter-domain routers do not have to understand policies, they
        simply have to mechanically follow the source route.



Dixon                                                           [Page 4]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


      - Routers do not have to store context identifying routes, since
        the information is specified in each packet header.

      - Route servers can be located anywhere in the network, provided
        the hosts know how to find them.

2.4 Encapsulation

   Encapsulation is the ability to enclose a network-layer packet within
   another one so that the actual packet can be directed via a path it
   would not otherwise take to a router that can remove the outermost
   packet and direct the resultant packet to its destination.
   Encapsulation requires:

      a.  An indication in the packet that it contains another packet.

      b.  A function in routers which, on receiving such a packet,
          removes the encapsulation and re-enters the forwarding process.

   All the proposals support encapsulation. Note that it is possible to
   achieve the effect of source routing by suitable encapsulation by the
   source.

2.5 Multicast

   The specification of addresses to permit multicast with various
   scopes can be accomodated by all the proposals. Internet-wide
   multicast is, of course, for further study!

2.6 Fragmentation

   All the proposals support the fragmentation of packets by
   intermediate routers, though there has been some recent discussion of
   removing this mechanism from some of the proposals and requiring the
   use of an MTU-discovery process to avoid the need for fragmentation.
   Such a decision would effectively preclude the use of transport
   protocols which use message-count sequence numbering (such as OSI
   Transport) over the network, as only protocols with byte-count
   acknowledgement (such as TCP) can deal with MTU reductions during the
   lifetime of a connection. OSI Transport may not be particularly
   relevant to the IP community (though it may be of relevance to
   commercial suppliers providing multiprotocol services), however the
   consequences for the types of services which may be supported over
   IPng should be noted.