RFC 1347

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

Okay bestie, this is RFC 1347 from the Network Working Group, dated June 1992 and written by Ross Callon at DEC 💖. It's an informational memo, so it gives info to the Internet community but doesn't set an Internet standard. Distribution is unlimited 🌈. The header doesn't list anything it obsoletes or updates ✨.

---

Status of the Memo 📜

So this memo is informational 🦋. It's giving "here's some info," not "here's a standard you must follow." And you're free to share it, because distribution is unlimited 💜.

1 Summary ✨

Okay so the Internet is running out of room 😭. The current IP address space is no longer enough for global addressing and routing, and it's causing two big problems. First, backbones and regionals have to keep track of a huge pile of routing information, and that pile is growing fast, roughly doubling each year 📈. Second, the Internet is running out of IP network numbers to hand out 💀. So we urgently need an approach to addressing and routing that fixes this and can scale to several orders of magnitude bigger than today's Internet 🔥. The catch is that any change has to roll out bit by bit, so we get a graceful transition with zero service disruption 🫶 [1].

This paper describes a simple proposal that's a long-term solution for Internet addressing, routing, and scaling ✨. It's a gradual migration from the current Internet Suite, which is Internet applications running over TCP or UDP, running over IP, to an updated suite. The updated suite is the same applications running over TCP or UDP, running over CLNP [2]. This approach is called "TUBA" (TCP & UDP with Bigger Addresses) 🎀.

This paper describes how the transition could happen 🧚. It does not cover how CLNP, NSAP addresses, and the related network and Internet layer protocols (ES-IS, IS-IS, and IDRP) let us scale to a very large, ubiquitous worldwide Internet. That's outside the scope of this paper 🙈.

Originally, people thought a practical proposal had to fix the immediate short-term routing information explosion too, not just the long-term scaling problem 💅. Because of the excessive routing info in IP backbones, older IP-based systems might have needed to talk to each other across backbones that didn't support IP at all 😬. That would mean either translating IP packets into CLNP packets and back again, or encapsulating IP packets inside CLNP packets. But other shorter-term techniques, like the one in [3], were proposed so the Internet could keep running for several years on the current IP address space 🌸. That buys time for the IP-to-CLNP migration, and that in turn lets us use a much simpler migration technique ✨.

So TUBA uses a simple long-term migration plan 🦋. It works by gradually updating Internet hosts, so they run Internet applications over CLNP, and updating DNS servers, so they return larger addresses 💖. The proposal says routers have to be updated to forward CLNP as well as IP 🔥. But it does not need encapsulation, translation, or address mapping, which is so iconic 👑. IP addresses and NSAP addresses can be assigned and used independently during the migration period, and routing and forwarding of IP and CLNP packets can also be done independently 🌈.

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

2 Long-Term Goal of TUBA 🌟

This proposal is all about taking advantage of the success of the Internet Suite 💅. The biggest part of that success is probably IP itself ✨. IP gives us a ubiquitous network service based on datagram (connectionless) operation, plus globally significant IP addresses that are structured to help routing 🎀. The unfortunate part is that the limited 32-bit IP address is slowly becoming inadequate for routing and addressing a global Internet 😭. To scale to the anticipated future size of the worldwide Internet, we need much larger addresses that allow a multi-level hierarchical address assignment 🌸.

If we could start over from scratch, we'd probably base the Internet on a new datagram internet protocol with much larger, multi-level addresses 🧚. In principle there are lots of options for that. The current IP could be augmented with larger addresses, or a brand-new protocol could be developed 💖. But developing, standardizing, implementing, testing, debugging, and deploying a new protocol (along with its routing and host-to-router protocols) would take a massive amount of time and energy, and it's not guaranteed to work out 💀. Plus, there's already a protocol available: the ConnectionLess Network Protocol (CLNP [1]). It's very similar to IP and offers the datagram service and address flexibility we need 🔥. CLNP is already being deployed in Internet backbones and regionals, and it's available in vendor products 🦋. This proposal doesn't actually require CLNP, since its main content is a graceful migration path from the current IP to a new IP with a larger address space. But the proposal does assume CLNP will be used 🫶.

This proposal is also trying to minimize the risk of migrating to a new IP address space 👑. It's motivated by the need for the Internet to scale, which means Internet applications running in a very large, ubiquitous worldwide Internet 🌈. So the plan is for existing Internet transport and application protocols to keep working unchanged, except that 32-bit IP addresses get replaced with larger ones 💅. Larger addresses will affect some applications, especially the Domain Name Service ⚠️. And no, TUBA doesn't mean moving over to OSI completely 🙅. It only replaces IP with CLNP. TCP, UDP, and the traditional TCP/IP applications would all run on top of CLNP ✨.

The long-term goal of TUBA is a worldwide Internet that works pretty much like today's, except CLNP replaces IP and NSAP addresses replace IP addresses 💖. Operation of this updated protocol suite will be very similar to what we have now 🎀. For example, to start talking to another host, a host gets an internet address the same way it normally does, except the address is bigger 🧚. In most cases, that means the host asks the DNS server to map a known DNS name to an internet address, then sends application packets encapsulated in TCP or UDP, which are then encapsulated in CLNP 🔥. This long-term goal needs a spec for how TCP and UDP run over CLNP 📝. DNS servers also need updating to deal with NSAP addresses, and routers need updating to forward CLNP packets 🌸. This proposal doesn't involve any wider migration to OSI protocols 💅.

TUBA doesn't actually depend on DNS to work 🫶. Any method used to get Internet addresses can be updated to return larger (NSAP) addresses, and then it can be used with TUBA ✨.

3 Migration 🦋

Okay here's the picture 🖼️. Figure 1 shows the basic operation of TUBA 💖. It shows a single Internet Routing Domain, which is also interconnected with Internet backbones and/or regionals 🌐. The figure has two "updated" Internet Hosts, N1 and N2, two older hosts, H1 and H2, a DNS server, and two border routers 🎀. We're assuming the routers inside the routing domain can forward both IP and CLNP traffic 🔥. That could be done either with multi-protocol routers that forward both protocol suites, or with a different set of routers for each suite 🧚.

                 ................    ................
                 .    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 💜. That means updated Internet hosts have to be able to send either old-style packets (using IP) or new-style packets (using CLNP) 😬. Which one to send is decided by the normal name-to-address lookup 🔍.

So say host N1 wants to talk to host H1 🙌. N1 asks its local DNS server for the address associated with H1 📡. Since H1 is an older, not-updated host, the address for H1 is an IP address, so the DNS response back to N1 specifies an IP address 💅. That tells N1 it needs to send a normal old-style Internet suite packet, encapsulated in IP, to H1 ✨.

Now say host N1 wants to talk to host N2 🫶. Again, N1 contacts the DNS server 🔥. If the routers in the domain haven't been updated to forward CLNP, or if the DNS resource record for N2 hasn't been updated, the DNS server will respond with a normal IP address. Then N1 and N2 communicate using IP (updated hosts in environments where the local routers don't handle CLNP are discussed in section 6.3) 🙈. But if the routers in the domain have been updated to forward CLNP, the DNS server has been updated to return NSAP addresses, and the right resource records for NSAP addresses have been configured into the DNS server, then the DNS server responds to N1 with the NSAP address for N2 🎉. That lets N1 know to use CLNP instead of IP to talk to N2 🦋.

So okay, the first bit is still about how the new record type fits in with the old one 💅 A brand new resource record type is gonna be defined for NSAP addresses. New hosts ask for both the new record and the old (IP address) resource records 🦋 Older DNS servers won't have the new record type, so they'll only send back IP address info 🙈 Updated DNS servers only have the new record info for the requested DNS name if the host attached to it has been updated. Otherwise the updated server just responds with an IP address again 🫶

Hosts and/or applications that don't use DNS do it kinda the same way ✨ Like, imagine local name to address records are kept in host table entries on every local workstation. When a workstation gets updated to run Internet applications over CLNP, its host table may also get updated NSAP addresses for other hosts that have been updated too 🌸 The entries for non-updated hosts would keep their IP addresses. So again, when an updated host wants to start talking to another host, it looks up the associated Internet address the normal way. If what comes back is a normal 32-bit IP address, the host starts the request with an Internet application over TCP (or UDP) over IP, as it does right now 💖 If the returned address is a longer NSAP address, the host starts the request with an Internet application over TCP (or UDP) over CLNP 🧚

---

4 Running TCP and UDP Over CLNP ✨

TCP runs directly on top of CLNP, i.e., the TCP packet is encapsulated directly inside a CLNP packet, so the TCP header sits right after the CLNP header 🎀 Using TCP over CLNP is pretty straightforward. The only tricky bit is figuring out how to generate the TCP pseudo-header (the one used for generating the TCP checksum) 💅

Note that TUBA runs TCP over CLNP on an end-to-end basis. For example, there's no intention to translate CLNP packets into IP packets 👑 This means only "consenting updated systems" will be running TCP over CLNP, which in turn means that, for purposes of generating the TCP pseudoheader from the CLNP header, backward compatibility with existing systems is not an issue 🦋 So there are several options for how to generate the pseudoheader ✨ The pseudoheader could be set to all zeros, which would mean the TCP header checksum only covers the TCP header 😭 Or 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 the same goes 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 packet in the same manner that it's 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 pseudoheader 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 lets DNS names map to NSAP addresses, and it will contain entries for systems that can run Internet applications, over TCP or UDP, over CLNP 💖

The presence of a long-address resource record 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 can run OSI protocols for any other purpose 🙈 Also, the NSAP address used for running Internet applications (over TCP or UDP over CLNP) doesn't need to have any relationship with other NSAP addresses that 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 (used for both purposes), or it 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 it may not be assumed to contain the correct NSAP address for any other purpose 😭

The backward translation (from NSAP address to DNS name) is made possible by defining an associated resource record 🧚 This one is known as long-in-addr.arpa, and it's used in a manner analogous to the existing in-addr.arpa 💅

Updated Internet hosts, when starting 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 hasn't been updated yet, the long address resource record won't be available, and an error response will be returned. In that case, the updated hosts must then ask for the regular Internet address 🌈 This lets updated hosts be deployed in environments where the DNS servers haven't been updated yet 🍓

An updated DNS server, if asked for the long-address corresponding to a particular DNS name, does a normal DNS search to get the information 💜 If the long-address corresponding to that name isn't available, 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 where 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 keep entries in their databases that let them 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, the communication with the other DNS server can use CLNP. Otherwise, the interaction between DNS servers uses IP 🙈 Initially, it's likely that all communication between DNS servers will use IP, as it does 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 that point, the remaining older (not yet updated) IP hosts won't 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]). If necessary, it can also be postponed 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, the Internet will need to be split into "IP address domains" for purposes of IP addressing 🎀 32-bit IP addresses will only be meaningful within an address domain, which lets the old IP hosts keep being 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 so they can use Telnet or FTP to reach 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) that pass around and use IP addresses internally 💖 Migrating to a larger address space (whether based on CLNP or another protocol) will require either that these applications be limited to local use (within an "IP address domain" where 32-bit IP addresses are meaningful), or that they be updated to either: (i) Use larger network 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 deployed in networks that don't have CLNP service yet, or where CLNP service is available locally but not to the global Internet 🍓 In these cases, the updated Internet hosts will need to know to initially send all Internet traffic (or all non-local traffic) using IP, even when the remote system has also been updated 💜 There are several ways this can be accomplished, such as: (i) The host could contain 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" so it believes all remote requests are supposed to go to some particular server, and that server could step in 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 way to allow global communication between hosts that 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's possible to define a version of NAT that is "local" to an addressing domain. In that sense, (locally significant) IP packets are mapped to globally significant CLNP packets before exiting a domain, in a manner that's transparent to systems outside of the domain 🦋

NAT lets old systems keep being used globally without application gateways, at the cost of significant additional complexity and possibly performance costs (tied to translation or encapsulation of network packets at IP address domain boundaries) 💖 NAT does not address the problem of applications that pass around and use IP addresses internally 🙈

The details of Network Address Translation are outside the scope of this document 🧚

6.5 Streamlining Operation of CLNP ✨

CLNP has a bunch of optional and/or variable length fields 🫠 Like, CLNP lets addresses be any integral number of bytes up to 20 bytes in length 😭 So the plan is to "profile" CLNP to help streamline router operation ✨ For example, it might look like saying all Internet hosts will use an NSAP address of precisely 20 bytes in length 💅 It could also specify which optional fields (if any) will be present in all CLNP packets 🎀 That way, all CLNP packets sent by Internet hosts can use a constant header format, which speeds up header parsing in routers 🚀 Main character energy for routers, honestly 💖 The details of the Internet CLNP profile is for further study 🧚

7 References 📚

Okay, the reference list is giving bibliography realness 💅

• [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. 💀 That's the whole entry, bestie, so please don't go looking for a security section in here 🙈

9 Author's Address 🎀

Here's where to reach the author 💌

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