diff options
Diffstat (limited to 'doc/rfc/rfc1347.txt')
| -rw-r--r-- | doc/rfc/rfc1347.txt | 561 |
1 files changed, 561 insertions, 0 deletions
diff --git a/doc/rfc/rfc1347.txt b/doc/rfc/rfc1347.txt new file mode 100644 index 0000000..48ca9af --- /dev/null +++ b/doc/rfc/rfc1347.txt @@ -0,0 +1,561 @@ + + + + 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. + + + 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: 508-486-5009 + + Email: Callon@bigfut.lkg.dec.com + + + + + + + + + + + + + + + + + + + + + Callon [Page 9] + + |