rfc1347.txt

RFC 的详细文档！

        Network Working Group                                  Ross Callon
        Request for Comments: 1347                                     DEC
                                                                 June 1992



                    TCP and UDP with Bigger Addresses (TUBA),
              A Simple Proposal for Internet Addressing and Routing



        Status of the Memo

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


        1 Summary

        The Internet is approaching a situation in which the current IP
        address space is no longer adequate for global addressing
        and routing. This is causing problems including: (i) Internet
        backbones and regionals are suffering from the need to maintain
        large amounts of routing information which is growing rapidly in
        size (approximately doubling each year); (ii) The Internet is
        running out of IP network numbers to assign. There is an urgent
        need to develop and deploy an approach to addressing and routing
        which solves these problems and allows scaling to several orders
        of magnitude larger than the existing Internet. However, it is
        necessary for any change to be deployed in an incremental manner,
        allowing graceful transition from the current Internet without
        disruption of service. [1]

        This paper describes a simple proposal which provides a long-term
        solution to Internet addressing, routing, and scaling. This
        involves a gradual migration from the current Internet Suite
        (which is based on Internet applications, running over TCP or
        UDP, running over IP) to an updated suite (based on the same
        Internet applications, running over TCP or UDP, running over CLNP
        [2]). This approach is known as "TUBA" (TCP & UDP with Bigger
        Addresses).

        This paper describes a proposal for how transition may be
        accomplished. Description of the manner in which use of CLNP,
        NSAP addresses, and related network/Internet layer protocols
        (ES-IS, IS-IS, and IDRP) allow scaling to a very large ubiquitous
        worldwide Internet is outside of the scope of this paper.

        Originally, it was thought that any practical proposal needed to
        address the immediate short-term problem of routing information
        explosion (in addition to the long-term problem of scaling to a
        worldwide Internet). Given the current problems caused by
        excessive routing information in IP backbones, this could require
        older IP-based systems to talk to other older IP-based systems
        over intervening Internet backbones which did not support IP.
        This in turn would require either translation of IP packets into


        Callon                                                    [Page 1]


        RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992


        CLNP packets and vice versa, or encapsulation of IP packets
        inside CLNP packets. However, other shorter-term techniques (for
        example [3]) have been proposed which will allow the Internet to
        operate successfully for several years using the current IP
        address space. This in turn allows more time for IP-to-CLNP
        migration, which in turn allows for a much simpler migration
        technique.

        The TUBA proposal therefore 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.

        This paper provides a draft overview of TUBA. The detailed
        operation of TUBA has been left for further study.


        2 Long-Term Goal of TUBA

        This proposal seeks to take advantage of the success of the
        Internet Suite, the greatest part of which is probably the use of
        IP itself. IP offers a ubiquitous network service, based on
        datagram (connectionless) operation, and on globally significant
        IP addresses which are structured to aid routing. Unfortunately,
        the limited 32-bit IP address is gradually becoming inadequate
        for routing and addressing in a global Internet. Scaling to the
        anticipated future size of the worldwide Internet requires much
        larger addresses allowing a multi-level hierarchical address
        assignment.

        If we had the luxury of starting over from scratch, most likely
        we would base the Internet on a new datagram internet protocol
        with much larger multi-level addresses. In principle, there are
        many choices available for a new datagram internet protocol. For
        example, the current IP could be augmented by addition of larger
        addresses, or a new protocol could be developed. However, the
        development, standardization, implementation, testing, debugging
        and deployment  of a new protocol (as well as associated routing
        and host-to-router protocols) would take a very large amount of
        time and energy, and is not guaranteed to lead to success. In
        addition, there is already such a protocol available. In
        particular, the ConnectionLess Network Protocol (CLNP [1]) is
        very similar to IP, and offers the required datagram service and
        address flexibility. CLNP is currently being deployed in the
        Internet backbones and regionals, and is available in vendor
        products. This proposal does not actually require use of CLNP
        (the main content of this proposal is a graceful migration path
        from the current IP to a new IP offering a larger address space),


        Callon                                                    [Page 2]


        RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992


        but use of CLNP will be assumed.

        This 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. The use of larger addresses will
        have some effect on applications, particularly on the Domain Name
        Service. 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.

        The long term goal of the TUBA proposal involves transition to a
        worldwide Internet which operates much as the current Internet,
        but with CLNP replacing IP and with NSAP addresses replacing IP
        addresses. Operation of this updated protocol suite will be very
        similar to the current operation. For example, in order to
        initiate communication with another host, a host will obtain a
        internet address in the same manner that it normally does, except
        that the address would be larger. In many or most cases, this
        implies that the host would contact the DNS server, obtain a
        mapping from the known DNS name to an internet address, and send
        application packets encapsulated in TCP or UDP, which are in turn
        encapsulated in CLNP. This long term goal requires a
        specification for how TCP and UDP are run over CLNP. Similarly,
        DNS servers need to be updated to deal with NSAP addresses, and
        routers need to be updated to forward CLNP packets. This proposal
        does not involve any wider-spread migration to OSI protocols.

        TUBA does not actually depend upon DNS for its operation. Any
        method that is used for obtaining Internet addresses may be
        updated to be able to return larger (NSAP) addresses, and then
        can be used with TUBA.


        3 Migration

        Figure 1 illustrates the basic operation of TUBA. Illustrated is
        a single Internet Routing Domain, which is also interconnected
        with Internet backbones and/or regionals. Illustrated are two 
        "updated" Internet Hosts N1 and N2, as well as two older hosts H1
        and H2, plus a DNS server and two border routers. It is assumed
        that the routers internal to the routing domain are capable of
        forwarding both IP and CLNP traffic (this could be done either by
        using multi-protocol routers which can forward both protocol
        suites, or by using a different set of routers for each suite).







        Callon                                                    [Page 3]


        RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992




                         ................    ................
                         .    H1        .    .  Internet    .
                         .              .-R1-.              .
                         .  H2          .    .  Backbones   .
                         .        DNS   .    .              .
                         .              .    .     and      .
                         .      N1      .    .              .
                         .              .    .  Regionals   .
                         .          N2  .-R2-.              .
                         ................    ................

                           Key

                      DNS    DNS server
                       H     IP host
                       N     Updated Internet host
                       R     Border Router

                            Figure 1 - Overview of TUBA
  


        Updated Internet hosts talk to old Internet hosts using the
        current Internet suite unchanged. Updated Internet hosts talk to
        other updated Internet hosts using (TCP or UDP over) CLNP. This
        implies that updated Internet hosts must be able to send either
        old-style packets (using IP), or new style packet (using CLNP).
        Which to send is determined via the normal name-to-address
        lookup.

        Thus, suppose that host N1 wants to communicate with host H1. In
        this case, N1 asks its local DNS server for the address
        associated with H1. In this case, since H1 is a older
        (not-updated) host, the address available for H1 is an IP
        address, and thus the DNS response returned to N1 specifies an IP
        address. This allows N1 to know that it needs to send a normal
        old-style Internet suite packet (encapsulated in IP) to H1.

        Suppose that host N1 wants to communicate with host N2. In this
        case, again N1 contacts the DNS server. If the routers in the
        domain have not been updated (to forward CLNP), or if the DNS
        resource record for N2 has not been updated, then the DNS server
        will respond with a normal IP address, and the communication
        between N1 and N2 will use IP (updated hosts in environments
        where the local routers do not handle CLNP are discussed in
        section 6.3). However, assuming that the routers in the domain
        have been updated (to forward CLNP), that the DNS server has been
        updated (to be able to return NSAP addresses), and that the
        appropriate resource records for NSAP addresses have been
        configured into the DNS server, then the DNS server will respond
        to N1 with the NSAP address for N2, allowing N1 to know to use



        Callon                                                    [Page 4]


        RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992


        CLNP (instead of IP) for communication with N2.

        A new resource record type will be defined for NSAP addresses.
        New hosts ask for both the new and old (IP address) resource
        records. Older DNS servers will not have the new resource record
        type, and will therefore respond with only IP address
        information. Updated DNS servers will have the new resource
        record information for the requested DNS name only if the
        associated host has been updated (otherwise the updated DNS
        server again will respond with an IP address).

        Hosts and/or applications which do not use DNS operate in a
        similar method. For example, suppose that local name to address
        records are maintained in host table entries on each local
        workstation. When a workstation is updated to be able to run
        Internet applications over CLNP, then the host table on the host
        may also be updated to contain updated NSAP addresses for other
        hosts which have also been updated. The associated entries for
        non-updated hosts would continue to contain IP addresses. Thus,
        again when an updated host wants to initiate communication with
        another host, it would look up the associated Internet address in
        the normal manner. If the address returned is a normal 32-bit IP
        address, then the host would initiate a request using an Internet
        application over TCP (or UDP) over IP (as at present). If the
        returned address is a longer NSAP address, then the host would
        initiate a request using an Internet application over TCP (or
        UDP) over CLNP.