rfc1752.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Finally, most of the reviewers questioned the level of complexity in
   the SIPP autoconfiguration plans as well as in SIPP in general, other
   than the header itself.







Bradner & Mankin                                               [Page 15]

RFC 1752                Recommendation for IPng             January 1995


8.3 TUBA Reviews

   The reviewers generally felt that the most important thing that TUBA
   has offers is that it is based on CLNP and there is significant
   deployment of CLNP-capable routers throughout the Internet.  There
   was considerably less agreement that there was significant deployment
   of CLNP-capable hosts or actual networks running CLNP.  Another
   strong positive for TUBA is the potential for convergence of ISO and
   IETF networking standards.  A number of reviewers pointed out that,
   if TUBA were to be based on a changed CLNP then the advantage of an
   existing deployed infrastructure would be lost and that the
   convergence potential would be reduced.

   A number of aspects of CLNP were felt to be a problem by the
   reviewers including the inefficiencies introduced by the lack of any
   particular word alignment of the header fields, CLNP source route,
   the lack of a flow ID field, the lack of a protocol ID field, and the
   use of CLNP error messages in TUBA. The CLNP packet format or
   procedures would have to be modified to resolve at least some of
   these issues.

   There seems to be a profound disagreement within the TUBA community
   over the question of the ability of the IETF to modify the CLNP
   standards.  In our presentation in Houston we said that we felt that
   "clone and run" was a legitimate process.  This is also what the IAB
   proposed in "IP version 7". [IAB92]  The TUBA community has not
   reached consensus that this view is reasonable.  While many,
   including a number of the CLNP document authors, are adamant that
   this is not an issue and the IETF can make modifications to the base
   standards, many others are just as adamant that the standards can
   only be changed through the ISO standards process.  Since the
   overwhelming feeling within the IETF is that the IETF must 'own' the
   standards on which it is basing its future, this disagreement within
   the TUBA community was disquieting.

   For a number of reasons, unfortunately including prejudice in a few
   cases, the reviews of the TUBA proposals were much more mixed than
   for SIPP or CATNIP. Clearly TUBA meets the requirements for the
   ability to scale to large numbers of hosts, supports flexible
   topologies, is media independent and is a datagram protocol.  To the
   reviewers, it was less clear that TUBA met the other IPng
   requirements and these views varied widely.

   There was also disagreement over the advisability of using NSAPs for
   routing given the wide variety of NSAP allocation plans.  The
   Internet would have to restrict the use of NSAPs to those which are
   allocated with the actual underlying network topology in mind if the
   required degree of aggregation of routing information is to be



Bradner & Mankin                                               [Page 16]

RFC 1752                Recommendation for IPng             January 1995


   achieved.

8.4 Summary of Proposal Reviews

   To summarize, significant problems were seen in all three of the
   proposals. The feeling was that, to one degree or another, both SIPP
   and TUBA would work in the Internet context but each exhibited its
   own problems.  Some of these problems would have to be rectified
   before either one would be ready to replace IPv4, much less be the
   vehicle to carry the Internet into the future.  Other problems could
   be addressed over time.  CATNIP was felt to be too incomplete to be
   considered.

9. A Revised Proposal

   As mentioned above, there was considerable discussion of the
   strengths and weaknesses of the various IPng proposals during the
   IPng 'BigTen' retreat on May 19th and 20th 1994. [Knopper94b]  After
   this retreat Steve Deering and Paul Francis, two of the co-chairs of
   the SIPP Working Group, sent a message to the sipp mailing list
   detailing the discussions at the retreat and proposing some changes
   in SIPP. [Deering94a]

   The message noted "The recurring (and unsurprising) concerns about
   SIPP were:

   (1) complexity/manageability/feasibility of IPAE, and

   (2) adequacy/correctness/limitations of SIPP's addressing and routing
       model, especially the use of loose source routing to accomplish
       'extended addressing'".

   They "proposed to address these concerns by changing SIPP as follows:

   * Change address size from 8 bytes to 16 bytes (fixed-length).

   * Specify optional use of serverless autoconfiguration of the 16-byte
     address by using IEEE 802 address as the low-order ("node ID")
     part.

   * For higher-layer protocols that use internet-layer addresses as
     part of connection identifiers (e.g., TCP), require that they use
     the entire 16-byte addresses.

   * Do *not* use Route Header for extended addressing."






Bradner & Mankin                                               [Page 17]

RFC 1752                Recommendation for IPng             January 1995


   After considerable discussion on the sipp and big-internet mailing
   lists about these proposed changes, the SIPP working group published
   a revised version of SIPP [Deering94b], a new addressing architecture
   [Francis94], and a simplified transition mechanism [Gillig94a].
   These were submitted to the IPng Directorate for their consideration.

   This proposal represents a synthesis of multiple IETF efforts with
   much of the basic protocol coming from the SIPP effort, the
   autoconfiguration and transition portions influenced by TUBA, the
   addressing structure is based on the CIDR work and the routing header
   evolving out of the SDRP deliberations.

10. Assumptions

10.1 Criteria Document and Timing of Recommendation

   In making the following recommendations we are making two assumptions
   of community consensus; that the IPng criteria document represents
   the reasonable set of requirements for an IPng, and that a specific
   recommendation should be made now and that from this point on the
   IETF should proceed with a single IPng effort.

   As described above, the IPng Technical Criteria document [Kasten94]
   was developed in a open manner and was the topic of extensive
   discussions on a number of mailing lists.  We believe that there is a
   strong consensus that this document accurately reflects the
   community's set of technical requirements which an IPng should be
   able to meet.

   A prime topic of discussion on the big-internet mailing list this
   spring as well as during the open IPng directorate meeting in
   Seattle, was the need to make a specific IPng recommendation at this
   time.  Some people felt that additional research would help resolve
   some of the issues that are currently unresolved.  While others
   argued that selecting a single protocol to work on would clarify the
   picture for the community, focus the resources of the IETF on
   finalizing its details, and, since the argument that there were open
   research items could be made at any point in history, there might
   never be a 'right' time.

   Our reading of the community is that there is a consensus that a
   specific recommendation should be made now.  This is consistent with
   the views expressed during the ipdecide BOF in Amsterdam [Gross94]
   and in some of the RFC 1550 white papers [Carpen94a].

   There is no particular reason to think that the basic recommendation
   would be significantly different if we waited for another six months
   or a year.  Clearly some details which are currently unresolved could



Bradner & Mankin                                               [Page 18]

RFC 1752                Recommendation for IPng             January 1995


   be filled in if the recommendation were to be delayed, but the
   current fragmentation of the IETF's energies limits the efficiency of
   this type of detail resolution. Concentrating the resources of the
   IETF behind a single effort seems to us to be a more efficient way to
   proceed.

10.2 Address Length

   One of the most hotly discussed aspects of the IPng design
   possibilities was address size and format.  During the IPng process
   four distinct views were expressed about these issues:

   1. The view that 8 bytes of address are enough to meet the current
      and future needs of the Internet (squaring the size of the IP
      address space).  More would waste bandwidth, promote inefficient
      assignment, and cause problems in some networks (such as mobiles
      and other low speed links).

   2. The view that 16 bytes is about right.  That length supports easy
      auto-configuration as well as organizations with complex internal
      routing topologies in conjunction with the global routing topology
      now and well into the future.

   3. The view that 20 byte OSI NSAPs should be used in the interests of
      global harmonization.

   4. The view that variable length addresses which might be smaller or
      larger than 16 bytes should be used to embrace all the above
      options and more, so that the size of the address could be
      adjusted to the demands of the particular environment, and to
      ensure the ability to meet any future networking requirements.

   Good technical and engineering arguments were made for and against
   all of these views. Unanimity was not achieved, but we feel that a
   clear majority view emerged that the use of 16 byte fixed length
   addresses was the best compromise between efficiency, functionality,
   flexibility, and global applicability. [Mankin94]

11. IPng Recommendation

   After a great deal of discussion in many forums and with the
   consensus of the IPng Directorate, we recommend that the protocol
   described in "Simple Internet Protocol Plus (SIPP) Spec. (128 bit
   ver)" [Deering94b] be adopted as the basis for IPng, the next
   generation of the Internet Protocol.  We also recommend that the
   other documents listed in Appendix C be adopted as the basis of
   specific features of this protocol.




Bradner & Mankin                                               [Page 19]

RFC 1752                Recommendation for IPng             January 1995


   This proposal resolves most of the perceived problems, particularly
   in the areas of addressing, routing, transition and address
   autoconfiguration.  It includes the broad base of the SIPP proposal
   effort, flexible address autoconfiguration features, and a merged
   transition strategy.  We believe that it meets the requirements
   outlined in the IPng Criteria document and provides the framework to
   fully meet the needs of the greater Internet community for the
   foreseeable future.

11.1 IPng Criteria Document and IPng

   A detailed review of how IPng meets the requirements set down in the
   IPng Criteria document [Kasten94] will soon be published.  Following
   is our feelings about the extent to which IPng is responsive to the
   criteria.

   * complete specification - the base specifications for IPng are
     complete but transition and address autoconfiguration do remain to
     be finalized
   * architectural simplicity - the protocol is simple, easy to explain
     and uses well established paradigms
   * scale - an address size of 128 bits easily meets the need to
     address 10**9 networks even in the face of the inherent
     inefficiency of address allocation for efficient routing
   * topological flexibility - the IPng design places no constraints on
     network topology except for the limit of 255 hops
   * performance - the simplicity of processing, the alignment of the
     fields in the headers, and the elimination of the header checksum
     will allow for high performance handling of IPng data streams
   * robust service - IPng includes no inhibitors to robust service and
     the addition of packet-level authentication allows the securing of
     control and routing protocols without having to have separate
     procedures
   * transition - the IPng transition plan is simple and realistically
     covers the transition methods that will be present in the
     marketplace
   * media independence - IPng retains IPv4's media independence, it may
     be possible to make use of IPng's Flow Label in some connection-