Network Working Group Zheng Wang Internet-Draft University College London October 1992 Transition to the Future Internet Protocol a comparison of three transition schemes 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 obsoleted 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 I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Summary A number of schemes have been put forward to replace the current IP with a new internet protocol. In this memo, we examine the issues in the transition to a new internet protocol. Three schemes are compared in detail. Introduction The Internet faces two serious scaling problems: address exhaustion and routing explosion. A number of schemes have been put forward to replace the current IP with a new internet protocol [1-6]. However, transition to a new internet protocol can be a long and painful process. It is important that the transition aspects of the proposed schemes be carefully looked at. From the perspective of transition, there are two basic approaches for the future internet protocol: 1) A evolutionary approach that attempts to maintain maximum back- ward compatibility in the header format with the current IP and minimize the modifications to the current IP systems. Expires: 12/1992 [Page 1] Internet-Draft October 1992 2) A revolutionary approach that simply replaces the current IP with a completely new header format. EIP and IPAE are two proposals based on the evolutionary approach. EIP achieves backward compatibility by making the extended space appears a new option to current IP systems [4]. IPAE adds a new layer above the IP so that the extended space appears to be user data to current IP systems [5]. CNAT outlined a translation mechanism for transition to a completely new header format [8]. In this paper, we look into the three transition strategies: EIP, IPAE and using a completely new header format, and compare the amount of modifications needed to current IP systems and the complexity of making the new and old systems interoperable. Note that EIP and IPAE are examined here as a transition mechanism rather than a complete protocol. The issue of routeing and addressing are not discussed here. Scenario One: Using a completely new header format In this section, we describe the modifications needed for transition to a NewIP with a completely new header format. Border Routers: a) all border routers have to be upgraded to the NewIP. Subnet Routers: a) all subnet routers have to be upgraded along the border routers. b) all subnet routers have to run both IP and NewIP. Domain Name Service: a) DNS servers have to be modified to provide mapping for new addresses. b) DNS servers have to provide mapping for both old and new addresses depending on the host that requests the mapping. Hosts: a) the upgraded hosts have to be assigned an new address in addition to the current IP address. b) the upgraded hosts have to run IP and NewIP in parallel. c) the upgraded hosts have to determine whether the destination host is upgreaded or not at the beginning of a connection. Expires: 12/1992 [Page 2] Internet-Draft October 1992 ARP/RARP: a) ARP/RARP header format has to be changed to accommodate the new type of addresses. b) the upgraded hosts and routers have to run both the old and new ARP/RARP protocols. ICMP: a) ICMP header format has to be changed as the ICMP data contains the IP header. b) upgraded hosts and routers have to run both old and new ICMP protocols. TCP/UDP: a) the pseudo headers in the checksum have to be modified to use the new addresses or set to zero. b) the upgraded hosts have to construct different pseudo headers depending on whether the destination host is upgraded or not. FTP/RPC/SNMP: a) the applications that pass addresses as data, such as the FTP's DATA PORT (PORT) command used at the beginning of each file transfer, have to be changed. Translation Service for IP Packets: a) the translation has to be done on out-going IP packets. b) the translation has to be done on in-coming packets destined to IP hosts. Translation Service for ICMP Packets: a) ICMP packets have to be translated differently from IP packets since the ICMP includes the IP header and 64 bytes data as the ICMP data, and the whole ICMP is then encapsulated in the IP header. b) if the translation is done by encapsulation, the router has to first translate the NewIP packet back to an IP packet, then form the ICMP, next encapsulate the ICMP in IP header, finally this resultant IP packet is encapsulated in NewIP and sent off to the source. c) if the translation is done by conversion, the router has to convert the NewIP packet back to IP packet, then form the ICMP data, next encapsulate the ICMP data into NewIP. Expires: 12/1992 [Page 3] Internet-Draft October 1992 Scenario Two: Using EIP In this section, we describe the modifications needed for transition to a NewIP with EIP. Border Routers: a) all border routers have to be upgraded to the EIP. Subnet Routers: a) subnet routers do not have to be upgraded as long as the IP addresses are still unique. b) upgraded subnet routers run EIP only but can handle IP packets without any additional changes. Domain Name Service: a) DNS servers have to be modified to provide mapping for new addresses. b) only network numbers have to be updated. Hosts: a) the upgraded hosts needs to be assigned a network number and it can use the current IP address as the host number. b) the upgraded hosts run EIP only but can handle IP packets without additional changes. ARP/RARP: a) no changes are required. ICMP: a) no changes to the format are required. b) new ICMP messages may be added. TCP/UDP: a) no changes are required. FTP/RPC/SNMP: a) the applications that pass addresses as data, such as the FTP's DATA PORT (PORT) command used at the beginning of each file transfer, do not have to be changed before IP addresses run out. Expires: 12/1992 [Page 4] Internet-Draft October 1992 Translation Service for IP Packets: a) the translation needs to be done on out-going IP packets. b) no need for translation on in-coming packets to IP hosts. Translation Service for ICMP Packets: a) no special treatment is needed for ICMP packets. Scenario Three: Using IPAE In this section, we describe the modifications needed for transition to a NewIP with IPAE. Border Routers: a) all border routers have to be upgraded to IPAE. Subnet Routers: a) subnet routers do not have to be upgraded as long as the IP addresses are still unique. b) upgraded subnet routers run IPAE only but can handle IP packets without any additional changes. Domain Name Service: a) DNS servers have to be modified to provide mapping for new addresses. b) only network numbers have to be updated. Hosts: a) the upgraded hosts needs to be assigned a network number and it can use the current IP address as the host number. b) the upgraded hosts run IPAE only but can handle IP packets without additional changes. ARP/RARP: a) no changes are required. ICMP: a) changes to the format are required (see below Translation of ICMP packets for more details). b) new ICMP messages may be added. Expires: 12/1992 [Page 5] Internet-Draft October 1992 TCP/UDP: a) no changes are required. FTP/RPC/SNMP: a) the applications that pass addresses as data, such as the FTP's DATA PORT (PORT) command used at the beginning of each file transfer, do not have to be changed before IP addresses run out. Translation Service for IP Packets: a) the translation has to be done on out-going IP packets. b) the translation has to be on in-coming packets to IP hosts. Translation Service for ICMP Packets: a) ICMP packets have to be translated differently from IP packets since the ICMP includes the IP header and 64 bytes data as the ICMP data, and the whole ICMP is then encapsulated in the IP header. b) The translation has to be done to the IPAE header that carries ICMP data and the IPAE header that is included inside the ICMP data. c) The ICMP packets sent by IP hosts can not be translated because the 64-bit data included inside the ICMP data is not large enough to carry the network numbers and other information for translation [7]. This problem can cause programs such as "ping" unworkable. Discussion Using a completely new IP format effectively requires each host to run the new and old protocol stacks in parallel, which includes FTP/SNMP/RPC, UDP/TCP, IP, ARP/RARP, DNS and ICMP. EIP and IPAE mainatin some degree of backward compatibility by retaining some of the IP packet format. The difference between EIP and IPAE lies in ICMP. Since IPAE introduces an extra layer between transport and network layers, ICMP which has an IP header inside its data is a bit problematic. For EIP, ICMP requires no changes at all. Another possible difference between EIP and IPAE is that EIP allows new fields other than address (e.g. endpoint ids - Expires: 12/1992 [Page 6] Internet-Draft October 1992 EIDs) while IPAE does not. This is because IPAE does not use the extended fields within a single "commonwealth" while EIP allows hosts to use extended fields even within a single network. References [1] R. Callon, "TCP and UDP with Bigger Addresses (TUBA), a Simple Porposal for Internet Addressing and Routing", RFC-1347, June 1992. [2] P. Tsuchiya, "Pip: The 'P' Internet Protocol", Internet Draft, May 1992 [3] J. Noel Chiappa "A New IP Routing and Addressing Architecture", Internet Draft, 1992. [4] Z. Wang, "EIP: The Extended Internet Protocol - a framework for maintaining backward compatibility", Internet-Draft, July, 1992. [5] R. Hinden, D. Crocker, "A Proposal for IP Adress Encapsulation (IPAE): A Compatible Version of IP with Large Addresses", Internet-draft, July 1992. [6] S. Deering, "Simple Internet Protocol (SIP)", draft note, Sept, 1992. [7] C. Partridge, "Re: Note on implementing IPAE", in his message to Big-Interent@munnari.oz.au, 17 July 1992. [8] R. Callon, "Overview of a proposal for Internet Addressing and Routing", Internet-Draft, March 1992. Authors' Address: Zheng Wang Dept of Computer Science University College London London WC1E 6BT, UK z.wang@cs.ucl.ac.uk Expires: 12/1992 [Page 7]