Internet Draft J. Curran November 1992 BBN TCP & UDP with Network-independent Endpoints (TUNE) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or rendered obsolete by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This memo proposes a strategy for providing TCP and UDP services over _multiple_ network services in a manner compatible with existing TCP/IP applications. By introducing network-independent endpoint identifiers for transport entities, TUNE makes it possible to change network addresses (and potentially network protocols) without impact to the application layer. While this paper describes the use of Connection-Less Network Protocol [1] as a possible long-term network service for the Internet, the overall approach differs from the "TCP & UDP with Bigger Addresses" [2] initiative due to the addition of network-independent endpoint identifiers. TUNE also provides network layer programming interfaces which are unchanged from those of the current Internet Protocol (IP) suite and hence alleviate the need for application code changes during initial deployment. Comments should be sent to the author (jcurran@nic.near.net). Curran Expires April, 1993 [Page 1] Internet Draft TUNE Overview November 1992 Acknowledgments Sincere thanks to the members of the TUBA mailing list who had to endure these ideas at very early stage, and in particular, thanks to Ross Callon, Dave Piscitello, and Paul Tsuchiya for bearing with my endless questions. Table of Contents 1 Introduction 2 TUNE Architecture 2.1 Endpoint Identifiers (EIDs) 2.2 EID Resolution 2.3 TUNE Header Format 3 TUNE Administration 3.1 Autoconfiguration 3.2 Portability 3.3 Mobility 4 Appendixes 5 Security Considerations 6 References 7 Author's Address 1.0 Introduction Recent growth in the Internet has revealed several significant scaling problems in the current Internet routing and addressing architecture. It is generally acknowledged that continued deployment of non-hierarchical addresses will result in unacceptable growth to transit routing tables in the Internet. While the "Classless Inter- Domain Routing" [3] approach to address assignment and route aggregation should minimize routing table explosion for the immediate future, it is not positioned as a long-term solution to the routing, addressing, and scaling problems. Curran Expires April, 1993 [Page 2] Internet Draft TUNE Overview November 1992 From a purely technical viewpoint, strict hierarchical addressing could be used to create a highly-scalable Internet routing architecture. Topologically-assigned addresses for network attachment points would minimize the need for routing information exchange. It would be necessary to use addresses of sufficient size to fully represent the network topology, but large hierarchical addressing plans have already been proposed for some protocol suites [4]. There are two minor administrative problems in using topologically- assigned addresses as a basis for long-term solution to the routing problem: Topologically-assigned addresses cannot provide organizations with geographic and service provider mobility. As a result, organizations using topologically-assigned addresses are forced into address migrations when relocating. While autoconfiguration and directory services may eventually minimize the use of network addresses in configurations, these services do not currently provide relief for network address changes. Furthermore, the existence of larger hierarchically-assigned addresses does not insure their usage by the thousands of applications which currently work over today's Internet. Several of the proposed routing and addressing solutions call for changing the programming interfaces for TCP and UDP services to support larger addresses. As a consequence, every existing network application will have be revised, and organizations will have to insure that they have the "upgraded" versions of all their network applications before moving to the new architecture. It will be necessary to phase in the usage of larger addresses in a controlled manner in order to bring about their acceptance by the Internet community. TCP & UDP with Network-independent Endpoints (TUNE) is one possible strategy for resolving the routing and addressing problems in the current Internet while accommodating existing applications. The TUNE architecture provides for the delivery of TCP and UDP messages in a manner similar to IP, but goes further by formally separating endpoint identification from network attachment information to improve mobility and scaling. By allowing the use of existing IP addresses as one class of endpoint identifiers, TUNE provides for an initial transition to TUNE services without application code changes. This document describes the overall TUNE architecture and a migration plan for transition to CLNP network services. While TUNE will function over almost any network service, CLNP's existing hierarchical network addressing will require minimal routing information exchange once TUNE is deployed. In addition, the Curran Expires April, 1993 [Page 3] Internet Draft TUNE Overview November 1992 availability of CLNP services in the current Internet will accelerate the deployment process and eliminate the risks associated with the development of a new network layer service. 2.0 TUNE Architecture TCP & UDP with Network-independent Endpoints (TUNE) details a convergence layer between the Internet transport and underlying network datagram delivery services. The purpose of this layer is to allow identification of transport endpoints independent of the underlying network addressing scheme. This is analogous to the role that the Address Resolution Protocol [5] plays in allowing network address selection unconstrained by physical interface address. TUNE's relationship to other network services can be depicted as follows: +---------------------------------------+ | (Applications) | + +------------------+ +====================+ DNS | Name Resolution | Transport Layer +__________________+ | TCP, UDP, etc. | + +------------------+ |====================+ TUNE | Endpoint Resolution | Network Layer +__________________+ | IP, CLNP, IPAE, SIP, etc. | | +------------------+ +====================+ ARP | Address Resolution | Data Link Layer +__________________+ | 802.3, DIX, SLIP, PPP, etc. | | | +---------------------------------------+ TUNE provides two functions: a mapping function from endpoint identifiers to network protocols and addresses, and the labeling of messages with transport endpoint identifiers. While TUNE is not required for successful implementation of TCP and UDP over new network protocols, the benefits of using TUNE include: o Globally unique endpoint identifiers which are independent of network attachment point. o Endpoint identifiers translated to network addresses in a manner transparent to the applications. o Underlying transport provided via multiple network services Curran Expires April, 1993 [Page 4] Internet Draft TUNE Overview November 1992 with diverse address formats. o Hiding of network layer information from higher layers. o Backward-compatible programming interfaces for TCP and UDP services, and application compatibility during transition. o Full utilization of the 32-bit Internet Protocol address space and its existing allocation infrastructure. o Interoperability between IP and TUNE hosts during transition. 2.1 Endpoint Identifiers (EIDs) Datagram-oriented transport protocols have traditionally used network layer addresses during the specification of communication endpoints. It is common for such network addresses to contain has some embedded information regarding the underlying network topology. IP addresses, for instance, implicitly identify the particular network which serves the end system. In the case of CLNP, addresses that are compatible with OSI Intra-domain IS-IS routing protocol [6] include explicit topological information in the "Area Address" (formed from the Initial Domain Part (IDP) and the High-order portion of the Domain Specific Part (HO-DSP) of a given NSAP.) Neither IP nor CLNP provide a endpoint identifier which is independent of network topology. As a result, topological information which is specific to the network must be made available to the applications for inclusion in their transport service requests. Likewise, applications using transport services become dependent upon the specific network attachment points at the time of configuration. TUNE transport services do not require specification of topology information (implied or otherwise) by applications. Communication is provided between globally unique "endpoint identifiers". These endpoint identifiers (EIDs) are assigned hierarchically (for administrative convenience and directory manageability) but do not embody any network topology information. A system with two interfaces (on the same or different networks) will use a single EID for normal communications. Additionally, when a system moves from one network to another, the endpoint identifier does not change. This provides TUNE with endpoint identifiers that are independent of network topology and inherently mobile. The success of a globally unique identification system depends ultimately upon the ease of obtaining identifiers. If the process for acquiring such an identifier is burdensome, then the probability of duplicate identifiers being used increases dramatically. For this Curran Expires April, 1993 [Page 5] Internet Draft TUNE Overview November 1992 reason, TUNE make use of existing allocation schemes for endpoint identifiers whenever possible. Appendix A contains a preliminary specification of the format and allocation process for EIDs. 2.2 EID Resolution In order to transport a TCP or UDP message to the appropriate endpoint, it will be necessary to determine the corresponding network service and address for any given EID. Given the current state of directory services in the Internet, the Domain Name System [7] is a likely choice for providing the EID to network address mapping function. One consequence of using DNS is that each TUNE system will require access to a DNS nameserver via a supported network protocol. Initially, it is anticipated that the existing IP nameservers will be used (with CLNP-only systems using transition services), but deployment of TUNE-supporting nameservers will occur as TUNE systems become more common. Appendix B specifies a DNS services plan for TUNE using the existing DNS software. This plan supports any NSAP format and provides flexibility in the selection of NSEL values for the TUNE service. Once the destination network service is determined, the TUNE message is passed to the appropriate network service along with the destination network address. Delivery of the message is handled as is normal for the particular network service selected; TUNE does not affect the datagram forwarding process in any manner. 2.3 TUNE Header Format Both TCP and UDP currently include a "pseudo-header" during checksum calculation. The pseudo-header includes the network-level source and destination along with the protocol identifier and transport message length. The purpose of this checksum is to insure that the message was delivered to the appropriate endpoint. Since an endpoint identifier is no longer related to the network layer addresses, the use of these pseudo-headers by TCP or UDP must be revised with new endpoint semantics. Under TUNE, the destination of TCP or UDP datagrams can be uniquely identified by the EID and the port number alone. It is not necessary for pseudo-headers to contain network addresses at all, since EIDs are globally unique. In addition, maintaining network addresses in these headers can actually prevent communications in some instances because the messages arrived via a different network protocol or interface than the sender intended. The elimination of network address information in these headers provides for consistent endpoint specification during Curran Expires April, 1993 [Page 6] Internet Draft TUNE Overview November 1992 mobility, and allows the use of multiple network services (with potentially different characteristics) by a single endpoint. The revised TCP and UDP pseudo-header for TUNE operations is: 0 7 8 15 16 23 24 31 +---------+---------+---------+---------+ | source endpoint id (octets 1-4) | +---------+---------+---------+---------+ | source endpoint id (octets 5-8) | +---------+---------+---------+---------+ | destination endpoint id (octets 1-4) | +---------+---------+---------+---------+ | destination endpoint id (octets 5-8) | +---------+---------+---------+---------+ | flags | protocol| data length | +---------+---------+---------+---------+ Since TUNE decouples the one-to-one relationship between network attachment points and transport endpoints, the specific destination EID must be available in the network or transport message so that messages for the destination system may recognized and processed. Source EIDs may also be desired in transport messages for logging, accounting, or authorization purposes. As part of the TUBA discussions, it has been suggested that these EIDs might be embedded in network addresses via various mappings. This restricts the choice of network addresses (to those conforming to the mapping algorithm), and such mapping may not be available over other network services. Another consequence of embedding EIDs into network addresses is that the resulting transport identifiers used by applications become dependent on network addressing structures and thus subject to change with network changes. TUNE maintains independence from network layer addresses by prepending TCP and UDP messages with the revised pseudo-header during delivery. This revised header (referred to as the "TUNE header") precedes the TCP or UDP data in a TUNE datagram and contains the protocol field needed for demultiplexing at the destination TUNE system. This is a significant departure from current IP architecture, and will result in larger network layer datagrams in most cases. While the addition of 24 octets to the average Internet datagram is considered heresy by many, the header will result in a minimal performance impact when used with large datagram sizes. The impact on low-speed circuits would be much greater, but may be alleviated through the use of header compression techniques in a manner similar to IP [8]. Curran Expires April, 1993 [Page 7] Internet Draft TUNE Overview November 1992 3.0 TUNE Administration By introducing organizational endpoint identifiers, TUNE creates basic infrastructure for several administrative features which have been previously viewed as network-layer services. In particular, EID identification of transport messages can simplify the deployment of autoconfiguration, portability, and mobility for end-systems. 3.1 Autoconfiguration In order for a TUNE system to properly interact with other TUNE systems, it must: o Have an operational network service o Know its own EID o Have access to the EID resolution service Autoconfiguration of network layer services has been sucessfully deployed for IP [9, 10], and is under development for CLNP services. As TUNE operates on top of network services, it does not interfere with the operation of any network-layer mechanisms. TUNE does provide an additional key which autoconfiguration techniques could use to gain hardware independence. Rather than utilizing an IEEE identifier from one of its network interfaces as a key for system information, (such as name and bootfile selection) it becomes possible to index such information by the EID, and have systems store (in a non-volatile memory) their EID. Changing either the network level address or the hardware address (such as board swap) would not affect the boot process. In some environments, it may be useful to store a secret key in addition to the EID for use via ticket granting service authorizing use of the EID. TUNE operation will require either non-volatile storage of the EID resolution service configuration or use of the autoconfiguration process to obtain such information. BOOTP is already capable of returning the necessary DNS information, but any additional information (such as network service preference) will have to be added as BOOTP extension or stored locally. 3.2 Portability Portability, loosely defined as the ability to carry a system somewhere and have it operate at the destination, has been considered Curran Expires April, 1993 [Page 8] Internet Draft TUNE Overview November 1992 a desirable characteristic of the Internet's next architecture. This is particularly true if portability is going to be used to maintain topologically-assigned network addresses. Since EIDs are not dependent upon any particular physical network, TUNE systems which are moved to a new network attachment point only need to update the EID-to-network-address mapping in order to achieve portability. This works regardless of the cause of the address change (physical move, provider change, etc.) Such address changes are completely transparent to applications under TUNE, since applications use EIDs. Due to the use of DNS services for EID->address mapping, TUNE cannot provide "instant" portability during its initial deployment. This stems from the inability to perform distributed updates to the DNS database from remote systems. Organizations will enjoy portability for all of their TUNE systems, but will have to manually update the EID mapping when systems are moved. The addition of dynamic update facilities could be done via DNS extensions for dynamic database update, or could be done as a separate facility which interacts directly with the master nameserver as needed. The advantage of a separate facility is the ability to readily add site-defined validation for such updates, whereas a DNS- based solution can readily be found during autoconfiguration and would not require specific autoconfiguration support as a result. Additional work is needed before making a determination for this topic. 3.3 Mobility Mobility, defined here as the ability to operate a system continuously while changing network location, has been expressed by many as a desirable characteristic of the next Internet architecture. Several mobile technologies including wireless LAN's, microwave personal communications services, and digital celluar services will become generally available over the next few years and could make significant demands upon our routing architecture if pressed to provide mobility to systems. In the TUNE model, mobility is provided at the transport layer. The TUNE header allows direction of transport messages without affecting the endpoint identifiers. Given two systems, EID XXX with network address NX1, and EID YYY with network address NY1, it is possible for XXX to move to a new network address (NX2) while communicating over CLNP as follows: Curran Expires April, 1993 [Page 9] Internet Draft TUNE Overview November 1992 XXX YYY --- --- Disconects from NX1/ connects to NX2 Sends dynamic update to EID map (identical to portability case) Cached mapping for XXX incorrect/ messages timeout. Cached ES info expires at last IS router based on holding timer. (holding timer presumably low for mobile host) Cached mapping for XXX incorrect/ messages report Host Unreachable. Failure causes reacquisition of EID -> address mapping. Mapping returns new information/ Messages to XXX/NX2 succeed. For TCP connections, the reaction time to network address changes can be minimized by using a "refresh EID" flag in the TUNE header. When a system changes its network address, this flag should be set in the next datagram to each outstanding TCP connection. 4.0 Appendix A: EID Allocation and Format TUNE Endpoint Identifiers are 64 bits in length, and may be represented in the familiar "dotted-decimal" notation used for IP addresses. The EIDs are allocated by the Internet Assigned Numbers Authority and its delegated authorities in accordance with the recommendations of the IETF. The IANA should allocate EIDs in contiguous blocks of EIDs to subordinate allocation authorities as necessary to insure an adequate supply of EIDs for TUNE-using organizations. It is recommended that the IANA make use of multiple channels for distribution of EIDs including network service providers, professional organizations, standards organizations, and others as necessary. In order to insure an plentiful supply of EID authorities, the first two octets of the EID are reserved for an allocation authority Curran Expires April, 1993 [Page 10] Internet Draft TUNE Overview November 1992 prefix. This allows for 64K allocation authorities. It is foreseeable that the IANA might supply multiple authority prefixes to some authorities so that further delegation of authority may occur. An example of this would be if the IANA were to allocate sufficient prefixes to ISO so that each country could have a unique authority prefix. Allocation authorities may allocate EIDs in any of the following sized blocks: 2**8, 2**16, 2**24, 2**32, 2**40, and 2**48. Authorities are required to maintain records of blocks assigned and provide support infrastructure (such as top-level directory servers) to allow successful EID resolution process for each block assigned. The requirements for directory services are intended to discourage small allocations by authorities, and it is expected that typical EID block allocations will consist of 2**16 or 2**24 EIDs per organization. In order to provide interoperability between IPv4 and TUNE systems, it is necessary to "map" existing IP addresses into TUNE EIDs. It is recommended that the following EIDs be reserved for this purpose: 128.0.x.y.z.0.0.n where 128.0 Authority Prefix x.y.z IP address (high 3 octets) 0.0.n IP address (low octet) Although this method of allocation does not provide a straightforward translation for existing IP addresess, it will allow existing network (and subnet) allocations to evolve into large EID namespaces prior to the establishment of multiple EID allocation authorities. 4.0 Appendix B: DNS Support for EID Resolution TUNE requires a distributed mapping function from a given EID to the appropriate network service and address used to reach it. This function will be initially provided through existing DNS services in order to allow timely deployment in the Internet. It is necessary to represent the EID information in the DNS namespace in a manner which supports delegation from the IANA to each assignment authority, and from each assignment authority to each organization. DNS has two restrictions upon how delegation may be performed: delegation may only occur on token boundaries (where tokens are delimited by periods in the name string), and information Curran Expires April, 1993 [Page 11] Internet Draft TUNE Overview November 1992 is organized with the rightmost tokens being most significant. Considering these requirements, the following approach is recommend for EID to network information mapping via DNS: The IANA will establish DNS service for a new domain: IN-EID.ARPA. For each authority prefix assignment, the IANA will delegate a subdomain of IN-EID.ARPA for management by the assignment authority. The subdomain may be determined by representing the authority prefix in dotted-decimal notation and inverting the order of tokens (as is done for the IN-ADDR domain currently) Example: Authority ABC is assigned prefix 0.47. A matching domain of 47.0.IN-EID.ARPA would be operated by or on behalf of the authority. For each organization prefix assigned, the authority will delegate a subdomain of their domain for management by the organization. The subdomain may be determined by representing the organization prefix in dotted-decimal notation and inverting the order of tokens (as above). The IANA will delegate subdomains for any organizations using EIDs based upon their IP network address allocation. Example: Organization XYZ is assigned prefix 0.47.255.238.0. A matching domain of 0.238.255.47.0.IN-EID.ARPA would be operated by or on behalf of organization XYZ. Organizations are responsibility for providing a pointer (PTR) record for each EID in use. The location for the PTR record may be determined by representing the EID in dotted-decimal notation and inverting the order of tokens (as above). The PTR record will contain the name of the network service used to reach the EID, a slash ("/") character, and a network address in a format specific to the network service. The valid names and address formats will be determined by the IANA. The use of PTR resource records requires that all address formats end with a period ("."). A network address may include a network layer protocol selector when available (e.g. NSEL in NSAP addresses) as TUNE only requires a Curran Expires April, 1993 [Page 12] Internet Draft TUNE Overview November 1992 single dispatch point and performs transport protocol demultiplexing internally based upon the TUNE header. TUNE hosts should only process address records for supported network protocols and should ignore all others received. The method for selecting which network service and address to use in the presence of multiple valid records is a local configuration issue, and not addressed here. It is conceivable that address selection might take local policy into consideration to provide limited source-specified routing. Examples: A system with EID of 128.0.192.52.71.0.0.4 reachable via CLNP might require a PTR record of the following form: 4.0.0.71.52.192.0.128.IN-EID.ARPA. PTR CLNS/47000580FFEE00000000001100AA00040084AF10. A system with EID of 0.47.255.238.0.0.1.178 reachable via PIP might require a PTR record of the following form: 178.1.0.0.238.255.47.0.IN-EID.ARPA PTR PIP/7.66000.77.18.2. 5.0 Security Considerations Security considerations are not discussed in this memo, but should be thoroughly explored before any future Internet architecture is selected. 6.0 References [1] "Protocol for Providing the Connectionless-Mode Network Service", ISO 8473, 1988. [2] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing", RFC1347, 1992 June. [3] Fuller, V.; Li, T.; Yu, J.; Varadhan, K, "Supernetting: an Address Assignment and Aggregation Strategy", RFC1338, 1992 June. Curran Expires April, 1993 [Page 13] Internet Draft TUNE Overview November 1992 [4] Collela, R.; Gardner, E.P.; Callon, R.W., "Guidelines for OSI NSAP allocation in the internet", RFC1237, 1991 July. [5] Plummer, D.C., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", RFC826, 1982 November. [6] Oran, David, Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC1142, February 1990. [7] Mockapetris, P., "Domain names - Concepts and Facilities", RFC1034, November 1987. [8] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC1144, 1990 February. [9] Croft, W.J.; Gilmore, J., "Bootstrap Protocol", RFC951, 1985 September. [10] Reynolds, J.K., "BOOTP vendor information extensions", RFC1084, 1988 December. 7.0 Author's Address: John Curran Bolt Beranek and Newman, Inc. 10 Moulton Street Cambridge, MA 02138 (617) 873-4398 jcurran@nic.near.net Curran Expires April, 1993 [Page 14]