rfc1454.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 843 行 · 第 1/3 页


RFC 1454        Comparison of Next Version IP Proposals         May 1993


   Note that providing some level of security implies manual
   configuration of security information within the network and must be
   considered in relationship to auto-configuration goals.

5. WHAT MAKES THE PROPOSALS DIFFERENT?

   Each proposal is about as different to the others as it is to IPv4 -
   that is the differences are small in principle, but may have
   significant effects (extending the size of addresses is only a small
   difference in principle!). The main distinct characteristics are:

   PIP:

      PIP has an innovative header format that facilitates hierarchical,
      policy and virtual-circuit routing. It also has "opaque" fields in
      the header whose semantics can be defined differently in different
      administrative domains and whose use and translation can be
      negotiated across domain boundaries. No control protocol is yet
      specified.

   SIP:

      SIP offers a "minimalist" approach - removing all little-used
      fields from the IPv4 header and extending the size of addresses to
      (only) 64 bits. The control protocol is based on modifications to
      ICMP. This proposal has the advantages of processing efficiency
      and familiarity.

   TUBA:

      TUBA is based on CLNP (ISO 8473) and the ES-IS (ISO 9542) control
      protocol. TUBA provides for the operation of TCP transport and UDP
      over a CLNP network. The main arguments in favour of TUBA are that
      routers already exist which can handle the network-layer protocol,
      that the extensible addresses offer a wide margin of "future-
      proofing" and that there is an opportunity for convergence of
      standards and products.

5.1 PIP

   PIP packet headers contain a set of instructions to the router's
   forwarding processor to perform certain actions on the packet. In
   traditional protocols, the contents of certain fields imply certain
   actions; PIP gives the source the flexibility to write small
   "programs" which direct the routing of packets through the network.

   PIP addresses have an effectively unlimited length: each level in the
   topological hierarchy of the network contributes part of the address



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


   and addresses change as the network topology changes. In a completely
   hierarchical network topology, the amount of routing information
   required at each level could be very small. However, in practice,
   levels of hierarchy will be determined more by commercial and
   practical factors than by the constraints of any particular routing
   protocol. A greater advantage is that higher-order parts of the
   address may be omitted in local exchanges and that lower-order parts
   may be omitted in source routes, reducing the amount of topological
   information that host systems are required to know.

   There is an assumption that PIP addresses are liable to change, so a
   further quantity, the PIP ID, is assigned to systems for the purposes
   of identification. It isn't clear that this quantity has any purpose
   which could not equally be served by a DNS name [it is more compact,
   but equally it does not need to be carried in every packet and
   requires an additional lookup]. However, the problem does arise of
   how two potentially-communicating host systems find the correct
   addresses to use.

   The most complex part of PIP is that the meaning of some of the
   header fields is determined by mutual agreement within a particular
   domain. The semantics of specific processing facilities (for example,
   queuing priority) are registered globally, but the actual use and
   encoding of requests for these facilities in the packet header can be
   different in different domains. Border routers between two domains
   which use different encodings must map  from one encoding to another.
   Since routers may not only be adjacent physically to other domains,
   but also via "tunnels", the number of different encoding rules a
   router may need to understand is potentially quite large. Although
   there is a saving in header space by using such a scheme as opposed
   to the more familiar "options", the cost in the complexity of
   negotiating the use and encoding of these facilities, together with
   re-coding the packets at each domain border, is a subject of some
   concern. Although it may be possible for hosts to "precompile" the
   encoding rules for their local domain, there are many potential
   implementaion difficulties.

   Although PIP offers the most flexibility of the three proposals, more
   work needs to be done on "likely use" scenarios which make the
   potential advantages and disadvantages more concrete.

5.2 SIP

   SIP is simply IP with larger addresses and fewer options. Its main
   advantage is that it is even simpler that IPv4 to process. Its main
   disadvantages are:





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


      - It is far from clear that, if 32 bits of address are
        insufficient, 64 will be enough for the forseeable future;

      - although there are a few "reserved" bits in the header, the
        extension of SIP to support new features is not obvious.

   There's really very little else to say!

5.3 TUBA

   The characteristics of ISO CLNS are reasonably well known: the
   protocol bears a strong cultural resemblance to IPv4, though with
   20-byte network-layer addressing. Apart from a spurious "Not Invented
   Here" prejudice, the main argument againt TUBA is that it is rather
   too like IPv4, offering nothing other than larger, more flexible,
   addresses.  There is proof-by-example that routers are capable of
   handling the (very) long addresses efficiently, rather less that the
   longer headers do not adversely impact network bandwidth.

   There are a number of objections to the proposed control protocol
   (ISO 9542):


      - My early experience is that the process by which routers
        discover hosts is inefficient and resource consuming for
        routers - and requires quite fine timer resolution on hosts -
        if large LANs are to be accomodated reasonably. Proponents of
        TUBA suggest that recent experience suggests that ARP is no
        better, but I think this issue needs examination.

      - The "redirect" mechanism is based on (effectively) LAN
        addresses and not network addresses, meaning that local routers
        can only "hand-off" complex routing decisions to other routers
        on the same LAN.  Equally, redirection schemes (such as that of
        IPv4) which redirect to network addresses can result in
        unnecessary extra hops.  Analysis of which solution is better
        is rather dependent on the scenarios which are constructed.

   To be fair, however, the part of the protocol which provides for
   router-discovery provides a mechanism, absent from other proposals,
   by which hosts can locate nearby gateways and potentially
   automatically configure their addresses.

6. Transition Plans

   It should be obvious that a transition which permits "old" hosts to
   talk to "new" hosts requires:




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


   Either:

      (a) That IPng hosts can also use IPv4 or
      (b) There is translation by an intermediate system

   and either:

      (c) The infrastructure between systems is capable of carrying both
          IPng and IPv4 or (d) Tunneling or translation is used to carry
          one protocol within another in parts of the network

   The transition plans espoused by the various proposals are simply
   different combinations of the above. Experience would tend to show
   that all these things will in fact happen, regardless of which
   protocol is chosen.

   One problem of the tunneling/translation process is that there is
   additional information (the extra address parts) which must be
   carried across IPv4 tunnels in the network. This can either be
   carried by adding an extra "header" to the data before encapsulation
   in the IPv4 packet, or by encoding the information as new IPv4 option
   types. In the former case, it may be difficult to map error messages
   correctly, since the original packet is truncated before return; in
   the latter case there is a danger of the packet being discarded (IPv4
   options are not self-describing and new ones may not pass through
   IPv4 routers). There is thus the possibility of having to introduce a
   "new" version of IPv4 in order to support IPng tunneling.

   The alternative (in which IPng hosts have two stacks and the
   infrastructure may or may not support IPng or IPv4) of course
   requires a mechanism for resolving which protocols to try.

7. Random Comments

   This is the first fundamental change in the Internet protocols that
   has occurred since the Internet was manageable as an entity and its
   development was tied to US government contracts. It was perhaps
   inevitable that the IETF/IESG/IAB structure would not have evolved to
   manage a change of this magnitude and it is to be hoped that the new
   structures that are proposed will be more successful in promoting a
   (useful) consensus. It is interesting to see that many of the
   perceived problems of the OSI process (slow progress, factional
   infighting over trivia, convergence on the lowest-common denominator
   solution, lack of consideration for the end-user) are in danger of
   attaching themselves to IPng and it will be interesting to see to
   what extent these difficulties are an inevitable consequence of wide
   representation and participation in network design.




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


   It could be regarded either as a sign of success or failure of the
   competitive process for the selection of IPng that the three main
   proposals  have few really significant differences. In this respect,
   the result of the selection process is not of particular
   significance, but the process itself is perhaps necessary to repair
   the social and technical cohesion of the Internet Engineering
   process.

8. Further Information

   The main discussion lists for the proposals listed are:

        TUBA:           [e-mail]
        PIP:            [e-mail]
        SIP:            [e-mail]
        General:        [e-mail]

        (Requests to: <list name>-request@<host>)

   Internet-Drafts and RFCs for the various proposals can be found in
   the usual places.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Tim Dixon
   RARE Secretariat
   Singel 466-468
   NL-1017AW Amsterdam
   (Netherlands)

   Phone: [phone] or + 44 91 232 0936
   EMail: [e-mail] or [e-mail]















Dixon                                                          [Page 15]