rfc1752.txt

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

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


7. IPng Proposals

   By the time that the IPng Area was formed, the IETF had already aimed
   a considerable amount of IETF effort at solving the addressing and
   routing problems of the Internet.  Several proposals had been made
   and some of these reached the level of having a working group
   chartered.  A number of these groups subsequently merged forming
   groups with a larger consensus.  These efforts represented different
   views on the issues which confront us and sought to optimize
   different aspects of the possible solutions.

   By February 1992 the Internet community developed four separate
   proposals for IPng [Gross92], "CNAT" [Callon92a], "IP Encaps"
   [Hinden92a], "Nimrod" [Chiappa91], and "Simple CLNP" [Callon92b].  By
   December 1992 three more proposals followed; "The P Internet
   Protocol" (PIP) [Tsuchiya92], "The Simple Internet Protocol" (SIP)
   [Deering92] and "TP/IX" [Ullmann93]. After the March 1992 San Diego
   IETF meeting "Simple CLNP" evolved into "TCP and UDP with Bigger
   Addresses" (TUBA) [Callon92c] and "IP Encaps" evolved into "IP
   Address Encapsulation" (IPAE) [Hinden92b].

   By November 1993, IPAE merged with SIP while still maintaining the
   name SIP. This group then merged with PIP and the resulting working
   group called themselves "Simple Internet Protocol Plus" (SIPP).  At
   the same time the TP/IX Working Group changed its name to "Common
   Architecture for the Internet" (CATNIP).

   None of these proposals were wrong nor were others right.  All of the
   proposals would work in some ways providing a path to overcome the
   obstacles we face as the Internet expands. The task of the IPng Area
   was to ensure that the IETF understand the offered proposals, learn
   from the proposals and provide a recommendation on what path best
   resolves the basic issues while providing the best foundation upon
   which to build for the future.

   The IPng Area evaluated three IPng proposals as they were described
   in their RFC 1550 white papers: CATNIP [McGovern94] , SIPP
   [Hinden94a] and TUBA. [Ford94a]. The IESG viewed Nimrod as too much
   of a research project for consideration as an IPng candidate.  Since
   Nimrod represents one possible future Internet routing strategy we
   solicited a paper describing any requirements Nimrod would put on an
   IPng to add to the requirements process. [Chiappa94]

7.1 CATNIP

   "Common Architecture for the Internet (CATNIP) was conceived as a
   convergence protocol. CATNIP integrates CLNP, IP, and IPX. The CATNIP
   design provides for any of the transport layer protocols in use, for



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


   example TP4, CLTP, TCP, UDP, IPX and SPX, to run over any of the
   network layer protocol formats: CLNP, IP (version 4), IPX, and
   CATNIP.  With some attention paid to details, it is possible for a
   transport layer protocol (such as TCP) to operate properly with one
   end system using one network layer (e.g., IP version 4) and the other
   using some other network protocol, such as CLNP." [McGovern94]

   "The objective is to provide common ground between the Internet, OSI,
   and the Novell protocols, as well as to advance the Internet
   technology to the scale and performance of the next generation of
   internetwork technology."

   "CATNIP supports OSI Network Service Access Point (NSAP) format
   addresses.  It also uses cache handles to provide both rapid
   identification of the next hop in high performance routing as well as
   abbreviation of the network header by permitting the addresses to be
   omitted when a valid cache handle is available. The fixed part of the
   network layer header carries the cache handles." [Sukonnik94]

7.2 SIPP

   "Simple Internet Protocol Plus (SIPP) is a new version of IP which is
   designed to be an evolutionary step from IPv4.  It is a natural
   increment to IPv4.  It was not a design goal to take a radical step
   away from IPv4.  Functions which work in IPv4 were kept in SIPP.
   Functions which didn't work were removed. It can be installed as a
   normal software upgrade in internet devices and is interoperable with
   the current IPv4.  Its deployment strategy was designed to not have
   any 'flag' days.  SIPP is designed to run well on high performance
   networks (e.g., ATM) and at the same time is still efficient for low
   bandwidth networks (e.g., wireless).  In addition, it provides a
   platform for new internet functionality that will be required in the
   near future." [Hinden94b]

   "SIPP increases the IP address size from 32 bits to 64 bits, to
   support more levels of addressing hierarchy and a much greater number
   of addressable nodes.  SIPP addressing can be further extended, in
   units of 64 bits, by a facility equivalent to IPv4's Loose Source and
   Record Route option, in combination with a new address type called
   'cluster addresses' which identify topological regions rather than
   individual nodes."

   "SIPP changes in the way IP header options are encoded allows for
   more efficient forwarding, less stringent limits on the length of
   options, and greater flexibility for introducing new options in the
   future. A new capability is added to enable the labeling of packets
   belonging to particular traffic 'flows' for which the sender requests
   special handling, such as non-default quality of service or 'real-



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


   time' service." [Hinden94a]

7.3 TUBA

   "The TCP/UDP Over CLNP-Addressed Networks (TUBA) proposal seeks to
   minimize the risk associated with migration to a new IP address
   space. In addition, this proposal is motivated by the requirement to
   allow the Internet to scale, which implies use of Internet
   applications in a very large ubiquitous worldwide Internet. It is
   therefore proposed that existing Internet transport and application
   protocols continue to operate unchanged, except for the replacement
   of 32-bit IP addresses with larger addresses.  TUBA does not mean
   having to move over to OSI completely. It would mean only replacing
   IP with CLNP. TCP, UDP, and the traditional TCP/IP applications would
   run on top of CLNP." [Callon92c]

   "The TUBA effort will expand the ability to route Internet packets by
   using addresses which support more hierarchy than the current
   Internet Protocol (IP) address space. TUBA specifies the continued
   use of Internet transport protocols, in particular TCP and UDP, but
   specifies their encapsulation in ISO 8473 (CLNP) packets.  This will
   allow the continued use of Internet application protocols such as
   FTP, SMTP, TELNET, etc.   TUBA seeks to upgrade the current system by
   a transition from the use of IPv4 to ISO/IEC 8473 (CLNP) and the
   corresponding large Network Service Access Point (NSAP) address
   space." [Knopper94]

   "The TUBA proposal makes use of a simple long-term migration proposal
   based on a gradual update of Internet Hosts (to run Internet
   applications over CLNP) and DNS servers (to return larger addresses).
   This proposal requires routers to be updated to support forwarding of
   CLNP (in addition to IP). However, this proposal does not require
   encapsulation nor translation of packets nor address mapping. IP
   addresses and NSAP addresses may be assigned and used independently
   during the migration period. Routing and forwarding of IP and CLNP
   packets may be done independently." ([Callon92c]

8. IPng Proposal Reviews

   The IPng Directorate discussed and reviewed the candidate proposals
   during its biweekly teleconferences and through its mailing list.  In
   addition, members of the Big-Internet mailing list discussed many of
   the aspects of the proposals, particularly when the Area Directors
   posted several specific questions to stimulate discussion. [Big]

   The directorate members were requested to each evaluate the proposals
   in preparation for a two day retreat held near Chicago on May 19th
   and 20th 1994.  The retreat opened with a roundtable airing of the



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


   views of each of the participants, including the Area Directors, the
   Directorate and a number of guests invited by the working group
   chairs for each for the proposals. [Knopper94b]  We will publish
   these reviews as well as a more detailed compendium review of each of
   the proposals as companion memos.

   The following table summarizes each of the three proposals reviewed
   against the requirements in the IPng Criteria document.  They do not
   necessarily reflect the views of the Area Directors.  "Yes" means the
   reviewers mainly felt the proposal met the specific criterion.  "No"
   means the reviewers mainly felt the proposal did not meet the
   criterion.  "Mixed" means that the reviewers had mixed reviews with
   none dominating. "Unknown" means that the reviewers mainly felt the
   documentation did not address the criterion.

                           CATNIP          SIPP            TUBA
                           ------          ----            ----
   complete spec           no              yes             mostly
   simplicity              no              no              no
   scale                   yes             yes             yes
   topological flex        yes             yes             yes
   performance             mixed           mixed           mixed
   robust service          mixed           mixed           yes
   transition              mixed           no              mixed
   media indepdnt          yes             yes             yes
   datagram                yes             yes             yes
   config. ease            unknown         mixed           mixed
   security                unknown         mixed           mixed
   unique names            mixed           mixed           mixed
   access to stds          yes             yes             mixed
   multicast               unknown         yes             mixed
   extensibility           unknown         mixed           mixed
   service classes         unknown         yes             mixed
   mobility                unknown         mixed           mixed
   control proto           unknown         yes             mixed
   tunneling               unknown         yes             mixed

8.1 CATNIP Reviews

   All the reviewers felt that CATNIP is not completely specified.
   However, many of the ideas in CATNIP are innovative and a number of
   reviewers felt CATNIP shows the best vision of all of the proposals.
   The use of Network Service Attachment Point Addresses (NSAPs) is well
   thought out and the routing handles are innovative.

   While the goal of uniting three major protocol families, IP, ISO-CLNP
   and Novell IPX is laudable our consensus was that the developers had
   not developed detailed enough plans to support realizing that goal.



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


   The plans they do describe suffer from the complexity of trying to be
   the union of a number of existing network protocols.  Some reviewers
   felt that CATNIP is basically maps IPv4, IPX, and SIPP addresses into
   NSAPs and, as such, does not deal with the routing problems of the
   current and future Internet.

   Additionally the reviewers felt that CATNIP has poor support for
   multicasting and mobility and does not specifically deal with such
   important topics as security and autoconfiguration.

8.2 SIPP Reviews

   Most of the reviewers, including those predisposed to other
   proposals, felt as one reviewer put it, that SIPP is an
   "aesthetically beautiful protocol well tailored to compactly satisfy
   today's known network requirements."  The SIPP Working Group has been
   the most dynamic over the last year, producing a myriad of
   documentation detailing almost all of the aspects necessary to
   produce a complete protocol description.

   The biggest problem the reviewers had with SIPP was with IPAE, SIPP's
   transition plan.  The overwhelming feeling was that IPAE is fatally
   flawed and could not be made to work reliably in an operational
   Internet.

   There was significant disagreement about the adequacy of the SIPP 64
   bit address size.  Although you can enumerate 10**15 end nodes in 64
   bits people have different views about how much inefficiency real-
   world routing plans introduce. [Huitema94]  The majority felt that 64
   bit addresses do not provide adequate space for the hierarchy
   required to meet the needs of the future Internet. In addition since
   no one has any experience with extended addressing and routing
   concepts of the type proposed in SIPP, the reviewers generally felt
   quite uncomfortable with this methodology.  The reviewers also felt
   that the design introduces some significant security issues.

   A number of reviewers felt that SIPP did not address the routing
   issue in any useful way.  In particular, there has been no serious
   attempt made at developing ways to abstract topology information or
   to aggregate information about areas of the network.