rfc1347.txt

RFC 的详细文档！

        4 Running TCP and UDP Over CLNP

        TCP is run directly on top of CLNP (i.e., the TCP packet is
        encapsulated directly inside a CLNP packet - the TCP header
        occurs directly following the CLNP header). Use of TCP over CLNP
        is straightforward, with the only non-trivial issue being how to
        generate the TCP pseudo-header (for use in generating the TCP
        checksum).

        Note that TUBA runs TCP over CLNP on an end-to-end basis (for
        example, there is no intention to translate CLNP packets into IP
        packets). This implies that only "consenting updated systems"
        will be running TCP over CLNP; which in turn implies that, for
        purposes of generating the TCP pseudoheader from the CLNP header,
        backward compatibility with existing systems is not an issue.
        There are therefore several options available for how to generate
        the pseudoheader. The pseudoheader could be set to all zeros
        (implying that the TCP header checksum would only be covering the
        TCP header). Alternatively, the pseudoheader could be calculated
        from the CLNP header. For example, the "source address" in the
        TCP pseudoheader could be replaced with two bytes of zero plus a
        two byte checksum run on the source NSAP address length and
        address (and similarly for the destination address); the
        "protocol" could be replaced by the destination address selector
        value; and the "TCP Length" could be calculated from the CLNP


        Callon                                                    [Page 5]


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


        packet in the same manner that it is currently calculated from
        the IP packet. The details of how the pseudoheader is composed is
        for further study.

        UDP is transmitted over CLNP in the same manner. In particular,
        the UDP packet is encapsulated directly inside a CLNP packet.
        Similarly, the same options are available for the UDP pseudo-
        header as for the TCP pseudoheader.


        5 Updates to the Domain Name Service

        TUBA requires that a new DNS resource record entry type
        ("long-address") be defined, to store longer Internet (i.e.,
        NSAP) addresses. This resource record allows mapping from DNS
        names to NSAP addresses, and will contain entries for systems
        which are able to run Internet applications, over TCP or UDP,
        over CLNP.

        The presence of a "long-address" resource record for mapping a
        particular DNS name to a particular NSAP address can be used to
        imply that the associated system is an updated Internet host.
        This specifically does  not imply that the system is capable of
        running OSI protocols for any other purpose. Also, the NSAP
        address used for running Internet applications (over TCP or UDP
        over CLNP) does not need to have any relationship with other NSAP
        addresses which may be assigned to the same host. For example, a
        "dual stack" host may be able to run Internet applications over
        TCP over CLNP, and may also be able to run OSI applications over
        TP4 over CLNP. Such a host may have a single NSAP address
        assigned (which is used for both purposes), or may have separate
        NSAP addresses assigned for the two protocol stacks. The
        "long-address" resource record, if present, may be assumed to
        contain the correct NSAP address for running Internet applications
        over CLNP, but may not be assumed to contain the correct NSAP
        address for any other purpose.

        The backward translation (from NSAP address to DNS name) is
        facilitated by definition of an associated resource record. This
        resource record is known as "long-in-addr.arpa", and is used in a
        manner analogous to the existing "in-addr.arpa".

        Updated Internet hosts, when initiating communication with
        another host, need to know whether that host has been updated.
        The host will request the address-class "internet address",
        entry-type "long-address" from its local DNS server. If the
        local DNS server has not yet been updated, then the long address
        resource record will not be available, and an error response will
        be returned. In this case, the updated hosts must then ask for
        the regular Internet address. This allows updated hosts to be
        deployed in environments in which the DNS servers have not yet
        been updated.

        An updated DNS server, if asked for the long-address


        Callon                                                    [Page 6]


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


        corresponding to a particular DNS name, does a normal DNS search
        to obtain the information. If the long-address corresponding to
        that name is not available, then the updated DNS server will
        return the resource record type containing the normal 32-bit IP
        address (if available). This allows more efficient operation
        between updated hosts and old hosts in an environment in which
        the DNS servers have been updated.

        Interactions between DNS servers can be done over either IP or
        CLNP, in a manner analogous to interactions between hosts. DNS
        servers currently maintain entries in their databases which allow
        them to find IP addresses of other DNS servers. These can be
        updated to include a combination of IP addresses and NSAP
        addresses of other servers. If an NSAP address is available, then
        the communication with the other DNS server can use CLNP,
        otherwise the interaction between DNS servers uses IP. Initially,
        it is likely that all communication between DNS servers will use
        IP (as at present). During the migration process, the DNS servers
        can be updated to communicate with each other using CLNP.


        6 Other Technical Details

        6.1 When 32-Bit IP Addresses Fail

        Eventually, the IP address space will become inadequate for
        global routing and addressing. At this point, the remaining older
        (not yet updated) IP hosts will not be able to interoperate
        directly over the global Internet. This time can be postponed by
        careful allocation of IP addresses and use of "Classless
        Inter-Domain Routing" (CIDR [3]), and if necessary by
        encapsulation (either of IP in IP, or IP in CLNP). In addition,
        the number of hosts affected by this can be minimized by
        aggressive deployment of updated software based on TUBA.

        When the IP address space becomes inadequate for global routing
        and addressing, for purposes of IP addressing the Internet will
        need to be split into "IP address domains". 32-bit IP addresses
        will be meaningful only within an address domain, allowing the
        old IP hosts to continue to be used locally. For communications
        between domains, there are two possibilities: (i) The user at an
        old system can use application layer relays (such as mail relays
        for 822 mail, or by Telnetting to an updated system in order to
        allow Telnet or FTP to a remote system in another domain); or
        (ii) Network Address Translation can be used [4].

        6.2 Applications which use IP Addresses Internally

        There are some application protocols (such as FTP and NFS) which
        pass around and use IP addresses internally. Migration to a
        larger address space (whether based on CLNP or other protocol)
        will require either that these applications be limited to local
        use (within an "IP address domain" in which 32-bit IP addresses
        are meaningful) or be updated to either: (i) Use larger network


        Callon                                                    [Page 7]


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


        addresses instead of 32-bit IP addresses; or (ii) Use some other
        globally-significant identifiers, such as DNS names.

        6.3 Updated Hosts in IP-Only Environments

        There may be some updated Internet hosts which are deployed in
        networks that do not yet have CLNP service, or where CLNP service
        is available locally, but not to the global Internet. In these
        cases, it will be necessary for the updated Internet hosts to
        know to initially send all Internet traffic (or all non-local
        traffic) using IP, even when the remote system also has been
        updated. There are several ways that this can be accomplished,
        such as: (i) The host could contains a manual configuration
        parameter controlling whether to always use IP, or to use IP or
        CLNP depending upon remote address; (ii) The DNS resolver on the
        host could be "lied to" to believe that all remote requests are
        supposed to go to some particular server, and that server could
        intervene and change all remote requests for long-addresses into
        requests for normal IP addresses.

        6.4 Local Network Address Translation

        Network Address Translation (NAT [4]) has been proposed as a
        means to allow global communication between hosts which use
        locally-significant IP addresses. NAT requires that IP addresses
        be mapped at address domain boundaries, either to globally
        significant addresses, or to local addresses meaningful in the
        next address domain along the packet's path. It is possible to
        define a version of NAT which is "local" to an addressing domain,
        in the sense that (locally significant) IP packets are mapped to
        globally significant CLNP packets before exiting a domain, in a
        manner which is transparent to systems outside of the domain.

        NAT allows old systems to continue to be used globally without
        application gateways, at the cost of significant additional
        complexity and possibly performance costs (associated with
        translation or encapsulation of network packets at IP address
        domain boundaries). NAT does not address the problem of
        applications which pass around and use IP addresses internally.

        The details of Network Address Translation is outside of the
        scope of this document.

        6.5 Streamlining Operation of CLNP

        CLNP contains a number of optional and/or variable length fields.
        For example, CLNP allows addresses to be any integral number of
        bytes up to 20 bytes in length. It is proposed to "profile" CLNP
        in order to allow streamlining of router operation. For example,
        this might involve specifying that all Internet hosts will use an
        NSAP address of precisely 20 bytes in length, and may specify
        which optional fields (if any) will be present in all CLNP
        packets. This can allow all CLNP packets transmitted by Internet



        Callon                                                    [Page 8]


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


        hosts to use a constant header format, in order to speed up
        header parsing in routers. The details of the Internet CLNP
        profile is for further study.


        7 References

        [1]    "The IAB Routing and Addressing Task Force: Summary
               Report", work in progress.

        [2]    "Protocol for Providing the Connectionless-Mode Network
               Service", ISO 8473, 1988.

        [3]    "Supernetting: An Address Assignment and Aggregation
               Strategy", V.Fuller, T.Li, J.Yu, and K.Varadhan, March 
               1992.

        [4]    "Extending the IP Internet Through Address Reuse", Paul
               Tsuchiya, December 1991.


        8 Security Considerations

        Security issues are not discussed in this memo.


        9 Author's Address

        Ross Callon
        Digital Equipment Corporation
        550 King Street, LKG 1-2/A19
        Littleton, MA  01460-1289

        Phone: [phone]

        Email: [e-mail]




















        Callon                                                    [Page 9]